Java™ Security Architecture (JDK1.2)
`
`Author: Li Gong (li.gong@sun.com)
`
`Date:
`
`October 2, 1998
`
`Version 1.0
`
`This document gives an overview of the motivation of the major security
`features that are being implemented for JDK 1.2, introduces the new classes
`and their usage, discusses the impact of this new architecture on existing code,
`and gives thoughts on writing security-sensitive code in the future.
`
`TCL EXHIBIT 1021
`Page 1 of 70
`
`

`
`© 1997-1998 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto,
`California 94303, U.S.A. All rights reserved.
`
`RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the United
`States Government is subject to the restrictions set forth in DFARS 252.227-7013
`(c)(1)(ii) and FAR 52.227-19.
`
`The release described in this manual may be protected by one or more U.S.
`patents, foreign patents, or pending applications. Sun Microsystems, Inc.
`(SUN) hereby grants to you a fully-paid, nonexclusive, nontransferable,
`perpetual, worldwide limited license (without the right to sublicense) under
`SUN’s intellectual property rights that are essential to practice this
`specification. This license allows and is limited to the creation and distribution
`of clean room implementations of this specification that: (i) include a complete
`implementation of the current version of this specification without subsetting
`or supersetting; (ii) implement all the interfaces and functionality of the
`standard java.* packages as defined by SUN, without subsetting or
`supersetting; (iii) do not add any additional packages, classes or methods to
`the java.* packages; (iv) pass all test suites relating to the most recent published
`version of this specification that are available from SUN six (6) months prior to
`any beta release of the clean room implementation or upgrade thereto; (v) do
`not derive from SUN source code or binary materials; and (vi) do not include
`any SUN binary materials without an appropriate and separate license from
`SUN.
`
`Sun, Sun Microsystems, Sun Microsystems Computer Corporation, the Sun
`logo, the Sun Microsystems Computer Corporation logo, Java, JavaSoft,
`JavaScript, and HotJava are trademarks or registered trademarks of Sun
`Microsystems, Inc. UNIX® is a registered trademark in the United States and
`other countries, exclusively licensed through X/Open Company, Ltd. All other
`product names mentioned herein are the trademarks of their respective
`owners.
`
`THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY
`KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED
`TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
`PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS PUBLICATION
`COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL
`ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION
`HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS
`OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE
`IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE
`PROGRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.
`
`ii
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 2 of 70
`
`

`
`Table of Contents
`
`1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
`1.1 The Original Sandbox Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
`1.2 Evolving the Sandbox Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
`
`2 New Protection Mechanisms -- Overview of Basic Concepts5
`
`3 Permissions and Security Policy. . . . . . . . . . . . . . . . . . . . . . 8
`3.1 The Permission Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
`3.1.1 java.security.Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
`3.1.2 java.security.PermissionCollection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
`3.1.3 java.security.Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
`3.1.4 java.security.UnresolvedPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
`3.1.5 java.io.FilePermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
`3.1.6 java.net.SocketPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
`3.1.7 java.security.BasicPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`3.1.8 java.util.PropertyPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`3.1.9 java.lang.RuntimePermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
`3.1.10 java.awt.AWTPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
`3.1.11 java.net.NetPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
`3.1.12 java.lang.reflect.ReflectPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
`3.1.13 java.io.SerializablePermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
`3.1.14 java.security.SecurityPermission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
`3.1.15 java.security.AllPermission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
`3.1.16 Discussion of Permission Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
`
`Java Security Architecture (JDK1.2)
`
`iii
`
`TCL EXHIBIT 1021
`Page 3 of 70
`
`

`
`3.1.17 How To Create New Types of Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
`3.2 java.security.CodeSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
`3.3 java.security.Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
`3.3.1 Policy File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
`3.3.2 Property Expansion in Policy Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
`3.3.3 Assigning Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
`3.3.4 Default System and User Policy Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
`3.3.5 Customizing Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
`3.4 java.security.GeneralSecurityException . . . . . . . . . . . . . . . . . . . . . . . . . . .31
`
`4 Access Control Mechanisms and Algorithms . . . . . . . . . . 32
`4.1 java.security.ProtectionDomain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
`4.2 java.security.AccessController. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
`4.2.1 Algorithm for Checking Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
`4.2.2 Handling Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
`4.3 Inheritence of Access Control Context . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
`4.4 java.security.AccessControlContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
`
`5 Secure Class Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
`5.1 Class Loader Class Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
`5.2 The Primordial Class Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
`5.3 Class Loader Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
`5.4 Class Resolution Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
`
`6 Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
`
`iv
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 4 of 70
`
`

`
`6.1 Managing Applets and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
`6.2 SecurityManager versus AccessController . . . . . . . . . . . . . . . . . . . . . . . . .46
`6.3 Auxiliary Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
`6.3.1 The Key and Certificate Management Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
`6.3.2 Policy Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
`6.3.3 The JAR Signing and Verification Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
`
`7 GuardedObject and SignedObject . . . . . . . . . . . . . . . . . . . 52
`7.1 java.security.GuardedObject and java.security.Guard. . . . . . . . . . . . . . . . .52
`7.2 java.security.SignedObject. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
`
`8 Discussion and Future Directions. . . . . . . . . . . . . . . . . . . . 57
`8.1 Users, Authentication, and Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
`8.2 Resource Consumption Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
`8.3 Arbitrary Grouping of Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
`8.4 Object-Level Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
`8.5 Subdividing Protection Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
`8.6 Running Applets with Signed Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
`
`9 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
`
`10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
`
`Java Security Architecture (JDK1.2)
`
`v
`
`TCL EXHIBIT 1021
`Page 5 of 70
`
`

`
`11 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
`
`12 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
`
`vi
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 6 of 70
`
`

`
`1 Introduction
`
`Since the inception of Java technology, there has been strong and growing
`interest around the security of the Java platform as well as new security issues
`raised by the deployment of Java technology.
`
`From a technology provider’s point of view, Java security includes two aspects:
`• Provide the Java platform (primarily through JDK) as a secure, ready-built
`platform on which to run Java-enabled applications in a secure fashion.
`• Provide security tools and services implemented in the Java programming
`language that enable a wider range of security-sensitive applications, for
`example, in the enterprise world.
`
`This document discusses issues related to the first aspect, where the customers
`for such technologies include vendors that bundle or embed Java technology in
`their products (such as browsers and operating systems).
`
`1.1 The Original Sandbox Model
`
`The original security model provided by the Java platform is known as the
`sandbox model, which existed in order to provide a very restricted
`environment in which to run untrusted code obtained from the open network.
`The essence of the sandbox model is that local code is trusted to have full
`access to vital system resources (such as the file system) while downloaded
`remote code (an applet) is not trusted and can access only the limited resources
`provided inside the sandbox. This sandbox model is illustrated in the figure
`below.
`
`Java Security Architecture (JDK1.2)
`
`1
`
`TCL EXHIBIT 1021
`Page 7 of 70
`
`

`
`JDK 1.0 Security Model
`
`remote code
`
`local code
`
`sandbox
`
`JVM
`
`valuable resources (files, etc.)
`
`The sandbox model was deployed through the Java Development Kit (JDK),
`and was generally adopted by applications built with JDK 1.0, including Java-
`enabled web browsers.
`
`Overall security is enforced through a number of mechanisms. First of all, the
`language is designed to be type-safe and easy to use. The hope is that the
`burden on the programmer is such that the likelihood of making subtle
`mistakes is lessened compared with using other programming languages such
`as C or C++. Language features such as automatic memory management,
`garbage collection, and range checking on strings and arrays are examples of
`how the language helps the programmer to write safe code.
`
`Second, compilers and a bytecode verifier ensure that only legitimate Java
`bytecodes are executed. The bytecode verifier, together with the Java Virtual
`Machine, guarantees language safety at run time.
`
`Moreover, a classloader defines a local name space, which can be used to
`ensure that an untrusted applet cannot interfere with the running of other
`programs.
`
`Finally, access to crucial system resources is mediated by the Java Virtual
`Machine and is checked in advance by a SecurityManager class that restricts
`the actions of a piece of untrusted code to the bare minimum.
`
`JDK 1.1 introduced the concept of a “signed applet”, as illustrated by the figure
`below. In that release, a correctly digitally signed applet is treated as if it is
`trusted local code if the signature key is recognized as trusted by the end
`system that receives the applet. Signed applets, together with their signatures,
`
`2
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 8 of 70
`
`

`
`are delivered in the JAR (Java Archive) format. In JDK 1.1, unsigned applets
`still run in the sandbox.
`
`JDK 1.1 Security Model
`
`remote code
`
`local code
`
`trusted
`
`sandbox
`
`JVM
`
`valuable resources (files, etc.)
`
`1.2 Evolving the Sandbox Model
`
`The new security architecture in JDK 1.2, illustrated in the figure below, is
`introduced primarily for the following purposes.
`
`JDK 1.2 Security Model
`local or remote code (signed or not)
`
`security policy
`
`class loader
`
`sandbox
`
`JVM
`
`valuable resources (files, etc.)
`
`codes run
`with different
`permissions,
`no built-in
`notion of
`trusted code
`
`Java Security Architecture (JDK1.2)
`
`3
`
`TCL EXHIBIT 1021
`Page 9 of 70
`
`

`
`• Fine-grained access control.
`
`This capability existed in the JDK from the beginning, but to use it, the
`application writer had to do substantial programming (e.g., by subclassing and
`customizing the SecurityManager and ClassLoader classes). The HotJava
`browser 1.0 is such an application, as it allows the browser user to choose from
`a small number of different security levels.
`
`However, such programming is extremely security-sensitive and requires
`sophisticated skills and in-depth knowledge of computer security. The new
`architecture will make this exercise simpler and safer.
`• Easily configurable security policy.
`
`Once again, this capability existed previously in the JDK but was not easy to
`use. Moreover, writing security code is not straightforward, so it is desirable to
`allow application builders and users to configure security policies without
`having to program.
`• Easily extensible access control structure.
`
`Up to JDK 1.1, in order to create a new access permission, you had to add a
`new check method to the SecurityManager class. The new architecture allows
`typed permissions (each representing an access to a system resource) and
`automatic handling of all permissions (including yet-to-be-defined
`permissions) of the correct type. No new method in the SecurityManager class
`needs to be created in most cases. (In fact, we have so far not encountered a
`situation where a new method must be created.)
`• Extension of security checks to all Java programs, including applications as
`well as applets.
`
`There is no longer a built-in concept that all local code is trusted. Instead, local
`code (e.g., non-system code, application packages installed on the local file
`system) is subjected to the same security control as applets, although it is
`possible, if desired, to declare that the policy on local code (or remote code) be
`the most liberal, thus enabling such code to effectively run as totally trusted.
`The same principle applies to signed applets and any Java application.
`
`Finally, an implicit goal is to make internal adjustment to the design of security
`classes (including the SecurityManager and ClassLoader classes) to reduce the
`risks of creating subtle security holes in future programming.
`
`4
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 10 of 70
`
`

`
`2 New Protection Mechanisms -- Overview of Basic Concepts
`
`We now go over, in some detail, the new protection architecture and give a
`brief explanation of its functionality. We start with an overview of the basic
`concepts behind the new architecture. We then introduce the major new classes
`in a natural order, starting with permission specifications, going on to the
`policy and related features, followed by access control and its usage, and then
`covering secure class loading and resolution.
`
`A fundamental concept and important building block of system security is the
`protection domain [Saltzer and Schroeder 75]. A domain can be scoped by the
`set of objects that are currently directly accessible by a principal, where a
`principal is an entity in the computer system to which permissions (and as a
`result, accountability) are granted. The sandbox utilized in JDK 1.0 is one
`example of a protection domain with a fixed boundary.
`
`The protection domain concept serves as a convenient mechanism for grouping
`and isolation between units of protection. For example, it is possible (but not
`yet provided as a built-in feature) to separate protection domains from
`interacting with each other so that any permitted interaction must be either
`through trusted system code or explicitly allowed by the domains concerned.
`Note that existing object accessibility rules remain valid under the new security
`architecture.
`
`Protection domains generally fall into two distinct categories: system domain
`and application domain. It is important that all protected external resources,
`such as the file system, the networking facility, and the screen and keyboard,
`be accessible only via system domains. The figure below illustrates the domain
`composition of a Java application environment.
`
`App-1
`
`App-2
`
`App-n
`
`system domain
`
`net I/O
`
`file I/O
`
`AWT
`
`printer
`
`Java Security Architecture (JDK1.2)
`
`5
`
`TCL EXHIBIT 1021
`Page 11 of 70
`
`

`
`A domain conceptually encloses a set of classes whose instances are granted
`the same set of permissions. Protection domains are determined by the policy
`currently in effect. The Java application environment maintains a mapping
`from code (classes and instances) to their protection domains and then to their
`permissions, as illustrated by the figure below.
`
`Class --> Domain --> Permissions
`
`e.class
`d.class
`c.class
`b.class
`a.class
`
`domain A
`
`permissions
`
`domain B
`
`permissions
`
`classes in
`Java runtime
`
`security policy
`
`A thread of execution (which is often, but not necessarily tied to, a single Java
`thread, which in turn is not necessarily tied to the thread concept of the
`underlying operation system) may occur completely within a single protection
`domain or may involve an application domain and also the system domain.
`For example, an application that prints a message out will have to interact with
`the system domain that is the only access point to an output stream. In this
`case, it is crucial that at any time the application domain does not gain
`additional permissions by calling the system domain. Otherwise, there can be
`serious security implications.
`
`In the reverse situation where a system domain invokes a method from an
`application domain, such as when the AWT system domain calls an applet’s
`paint method to display the applet, it is again crucial that at any time the
`effective access rights are the same as current rights enabled in the application
`domain.
`
`In other words, a less “powerful” domain cannot gain additional permissions
`as a result of calling or being called by a more powerful domain.
`
`6
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 12 of 70
`
`

`
`This discussion of one thread involving two protection domains naturally
`generalizes to a thread that traverses multiple protection domains. A simple
`and prudent rule of thumb for calculating permissions is the following:
`• The permission set of an execution thread is considered to be the
`intersection of the permissions of all protection domains traversed by the
`execution thread.
`• When a piece of code calls the doPrivileged method (see below), the
`permission set of the execution thread is considered to include a permission
`if it is allowed by the said code’s protection domain and by all protection
`domains that are called or entered directly or indirectly subsequently.
`
`As you can see, the doPrivileged method enables a piece of trusted code to
`temporarily enable access to more resources than are available directly to the
`application that called it. This is necessary in some situations. For example, an
`application may not be allowed direct access to files that contain fonts, but the
`system utility to display a document must obtain those fonts, on behalf of the
`user. We provide the doPrivileged method for the system domain to deal
`with this situation, and the method is in fact available to all domains.
`
`During execution, when access to a critical system resource (such as file I/O
`and network I/O) is requested, the resource-handling code directly or
`indirectly invokes a special AccessController class method that evaluates the
`request and decides if the request should be granted or denied.
`
`Such an evaluation follows and generalizes the “rule of thumb” given above.
`The actual way in which the evaluation is conducted can vary between
`implementations. The basic principle is to examine the call history and the
`permissions granted to the relevant protection domains, and to return silently
`if the request is granted or throw a security exception if the request is denied.
`
`Finally, each domain (system or application) may also implement additional
`protection of its internal resources within its own domain boundary. For
`example, a banking application may need to support and protect internal
`concepts such as checking accounts, deposits and withdrawals. Because the
`semantics of such protection is unlikely to be predictable or enforceable by the
`JDK, the protection system at this level is best left to the system or application
`developers. Nevertheless, whenever appropriate, we provide helpful
`primitives to simplify developers’ tasks. One such primitive is the
`SignedObject class, whose detail we will describe later.
`
`Java Security Architecture (JDK1.2)
`
`7
`
`TCL EXHIBIT 1021
`Page 13 of 70
`
`

`
`3 Permissions and Security Policy
`
`3.1 The Permission Classes
`
`The permission classes represent access to system resources. The
`java.security.Permission class is an abstract class and is subclassed, as
`appropriate, to represent specific accesses.
`
`As an example of a permission, the following code can be used to produce a
`permission to read the file named “abc” in the /tmp directory:
`
` perm = new java.io.FilePermission("/tmp/abc", "read");
`
`New permissions are subclassed either from the Permission class or one of its
`subclasses, such as java.security.BasicPermission. Subclassed permissions
`(other than BasicPermission) generally belong to their own packages. Thus,
`FilePermission is found in the java.io package.
`
`A crucial abstract method that needs to be implemented for each new class of
`permission is the implies method. Basically, “a implies b” means that if one is
`granted permission “a”, one is naturally granted permission “b”. This is
`important when making access control decisions.
`
`Associated with the abstract class java.security.Permission are the abstract class
`named java.security.PermissionCollection and the final class
`java.security.Permissions.
`
`Class java.security.PermissionCollection represents a collection (i.e., a set that
`allows duplicates) of Permission objects for a single category (such as file
`permissions), for ease of grouping. In cases where permissions can be added to
`the PermissionCollection object in any order, such as for file permissions, it is
`crucial that the PermissionCollection object ensure that the correct semantics
`are followed when the implies function is called.
`
`Class java.security.Permissions represents a collection of collections of
`Permission objects, or in other words, a super collection of heterogeneous
`permissions.
`
`Applications are free to add new categories of permissions that the system
`supports. How to add such application-specific permissions is discussed later
`in this document.
`
`Now we describe the syntax and semantics of all built-in permissions.
`
`8
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 14 of 70
`
`

`
`3.1.1 java.security.Permission
`
`This abstract class is the ancestor of all permissions. It defines the essential
`functionalities required for all permissions.
`
`Each permission instance is typically generated by passing one or more string
`parameters to the constructor. In a common case with two parameters, the first
`parameter is usually “the name of the target” (such as the name of a file for
`which the permission is aimed), and the second parameter is the action (such
`as “read” action on a file). Generally, a set of actions can be specified together
`as a comma-separated composite string.
`
`3.1.2 java.security.PermissionCollection
`
`This class holds a homogeneous collection of permissions. In other words,
`each instance of the class holds only permissions of the same type.
`
`3.1.3 java.security.Permissions
`
`This class is designed to hold a heterogeneous collection of permissions.
`Basically, it is a collection of java.security.PermissionCollection objects.
`
`3.1.4 java.security.UnresolvedPermission
`
`Recall that the internal state of a security policy is normally expressed by the
`permission objects that are associated with each code source. Given the
`dynamic nature of Java t echnology, however, it is possible that when the policy
`is initialized the actual code that implements a particular permission class has
`not yet been loaded and defined in the Java application environment. For
`example, a referenced permission class may be in a JAR file that will later be
`loaded.
`
`The UnresolvedPermission class is used to hold such “unresolved”
`permissions. Similarly, the class java.security.UnresolvedPermissionCollection
`stores a collection of UnresolvedPermission permissions.
`
`During access control checking on a permission of a type that was previously
`unresolved, but whose class has since been loaded, the unresolved permission
`is “resolved” and the appropriate access control decision is made. That is, a
`new object of the appropriate class type is instantiated, if possible, based on the
`information in the UnresolvedPermission. This new object replaces the
`UnresolvedPermission, which is removed.
`
`Java Security Architecture (JDK1.2)
`
`9
`
`TCL EXHIBIT 1021
`Page 15 of 70
`
`

`
`If the permission is still unresolvable at this time, the permission is considered
`invalid, as if it is never granted in a security policy.
`
`3.1.5 java.io.FilePermission
`
`The targets for this class can be specified in the following ways, where
`directory and file names are strings that cannot contain white spaces.
`
`file
`directory (same as directory/)
`directory/file
`directory/* (all files in this directory)
`* (all files in the current directory)
`directory/- (all files in the file system under this directory)
`- (all files in the file system under the current directory)
`"<<ALL FILES>>" (all files in the file system)
`
`Note that “<<ALL FILES>>” is a special string denoting all files in the system.
`On a Unix system, this includes all files under the root directory. On an MS-
`DOS system, this includes all files on all drives.
`
`The actions are: read, write, delete, and execute. Therefore, the following are
`valid code samples for creating file permissions:
`
`import java.io.FilePermission;
`
`FilePermission p = new FilePermission("myfile", "read,write");
`FilePermission p = new FilePermission("/home/gong/", "read");
`FilePermission p = new FilePermission("/tmp/mytmp", "read,delete");
`FilePermission p = new FilePermission("/bin/*", "execute");
`FilePermission p = new FilePermission("*", "read");
`FilePermission p = new FilePermission("/-", "read,execute");
`FilePermission p = new FilePermission("-", "read,execute");
`FilePermission p = new FilePermission("<<ALL FILES>>", "read");
`
`The implies method in this class correctly interprets the file system. For
`example, FilePermission(“/-”, “read,execute”) implies
`FilePermission(“/home/gong/public_html/index.html”, “read”), and
`FilePermission(“bin/*”, “execute”) implies FilePermission(“bin/emacs19.31”,
`“execute”).
`
`Note: Most of these strings are given in platform-dependent format. For
`example, to represent read access to the file named "foo" in the "temp"
`directory on the C drive of a Windows system, you would use
`
`10
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 16 of 70
`
`

`
`FilePermission p = new FilePermission("c:\\temp\\foo", "read");
`
`The double backslashes are necessary to represent a single backslash because
`the strings are processed by a tokenizer (java.io.StreamTokenizer), which allows
`“\” to be used as an escape string (e.g., “\n” to indicate a new line) and which
`thus requires two backslashes to indicate a single backslash. After the tokenizer
`has processed the above FilePermission target string, converting double
`backslashes to single backslashes, the end result is the actual path
`
`"c:\temp\foo"
`
`It is necessary that the strings be given in platform-dependent format until
`there is a universal file description language. Note also that the use of meta
`symbols such as “*” and “-” prevents the use of specific file names. We think
`this is a small limitation that can be tolerated for the moment. Finally, note that
`“/-” and “<<ALL FILES>>” are the same target on Unix systems in that they
`both refer to the entire file system. (They can refer to multiple file systems if
`they are all available). The two targets are potentially different on other
`operating systems, such as MS Windows and MacOS.
`
`Also note that a target name that specifies just a directory, with a “read” action,
`as in
`
`FilePermission p = new FilePermission("/home/gong/", "read");
`
`means you are only giving permission to list the files in that directory, not read any of
`them. To allow read access to files, you must specify either an explicit file name, or an
`“*” or “-”, as in
`
`FilePermission p = new FilePermission("/home/gong/myfile", "read");
`FilePermission p = new FilePermission("/home/gong/*", "read");
`FilePermission p = new FilePermission("/home/gong/-", "read");
`
`And finally, note that code always automatically has permission to read files
`from its same (URL) location, and subdirectories of that location; it does not
`need explicit permission to do so.
`
`3.1.6 java.net.SocketPermission
`
`This class represents access to a network via sockets. The target for this class
`can be given as “hostname:port_range”, where hostname can be given in the
`following ways:
`
`Java Security Architecture (JDK1.2)
`
`11
`
`TCL EXHIBIT 1021
`Page 17 of 70
`
`

`
`hostname (a single host)
`IP address (a single host)
`localhost (the local machine)
`"" (equivalent to "localhost")
`hostname.domain (a single host within the domain)
`hostname.subdomain.domain
`*.domain (all hosts in the domain)
`*.subdomain.domain
`* (all hosts)
`
`That is, the host is expressed as a DNS name, as a numerical IP address, as
`“localhost” (for the local machine) or as “” (which is equivalent to specifying
`“localhost”).
`
`The wildcard "*" may be included once in a DNS name host specification. If it
`is included, it must be in the leftmost position, as in "*.sun.com".
`
`The port_range can be given as follows:
`
`N (a single port)
`N- (all ports numbered N and above)
`-N (all ports numbered N and below)
`N1-N2 (all ports between N1 and N2, inclusive)
`
`Here N, N1, and N2 are non-negative integers ranging from 0 to 65535 (2^16-
`1).
`
`The actions on sockets are accept, connect, listen, and resolve (which is
`basically DNS lookup). Note that implicitly, the action “resolve” is implied by
`“accept”, “connect”, and “listen” -- i.e., those who can listen or accept
`incoming connections from or initiate out-going connections to a host should
`be able to look up the name of the remote host.
`
`Below are some examples of socket permissions.
`
`import java.net.SocketPermission;
`
`SocketPermission p = new SocketPermission("java.sun.com","accept");
`p = new SocketPermission("204.160.241.99","accept");
`p = new SocketPermission("*.com","connect");
`p = new SocketPermission("*.sun.com:80","accept");
`p = new SocketPermission("*.sun.com:-1023","accept");
`p = new SocketPermission("*.sun.com:1024-","connect");
`p = new SocketPermission("java.sun.com:8000-9000",
`
`12
`
`October 29, 1998
`
`TCL EXHIBIT 1021
`Page 18 of 70
`
`

`
` "connect,accept");
`p = new