| CONTENTS | PREV | NEXT |
A ProtectionDomain is constructed with a CodeSource, a ClassLoader, an array of Principals, and a collection of Permissions. The CodeSource encapsulates the codebase (java.net.URL) for all classes in this domain, as well as a set of certificates (of type java.security.cert.Certificate) for public keys that correspond to the private keys that signed all code in this domain. The Principals represent the user on whose behalf the code is running.
The permissions passed in at ProtectionDomain construction time represent a static set of permissions bound to the domain regardless of the Policy in force. The ProtectionDomain subsequently consults the current policy during each security check to retrieve dynamic permissions granted to the domain.
Classes from different CodeSources, or that are being executed on behalf of different principals, belong to different domains.
Today all code shipped as part of the Java 2 SDK is considered system code and run inside the unique system domain. Each applet or application runs in its appropriate domain, determined by policy.
It is possible to ensure that objects in any non-system domain cannot automatically discover objects in another non-system domain. This partition can be achieved by careful class resolution and loading, for example, using different classloaders for different domains. However, SecureClassLoader (or its subclasses) can, at its choice, load classes from different domains, thus allowing these classes to co-exist within the same name space (as partitioned by a classloader).
For example, the typical way to invoke access control has been the following code (taken from an earlier version of JDK):
ClassLoader loader = this.getClass().getClassLoader();
if (loader != null) {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead("path/file");
}
}
Under the new architecture, the check
typically should be invoked whether or not there is a classloader
associated with a calling class. It could be simply, for example:
FilePermission perm = new FilePermission("path/file", "read");
AccessController.checkPermission(perm);
The AccessController
checkPermission method examines the current execution
context and makes the right decision as to whether or not the
requested access is allowed. If it is, this check returns quietly.
Otherwise, an AccessControlException (a subclass of
java.lang.SecurityException) is thrown.
Note that there are (legacy) cases,
for example, in some browsers, where whether there is a
SecurityManager installed signifies one or the other security state
that may result in different actions being taken. For backward
compatibility, the checkPermission method on
SecurityManager can be used.
SecurityManager security = System.getSecurityManager();
if (security != null) {
FilePermission perm = new FilePermission("path/file", "read");
security.checkPermission(perm);
}
We currently do not change this aspect
of the SecurityManager usage, but would encourage application
developers to use new techniques introduced in the Java 2 SDK in
their future programming when the built-in access control algorithm
is appropriate.
The default behavior of the
SecurityManager checkPermission method is actually to
call the AccessController checkPermission method. A
different SecurityManager implementation may implement its own
security management approach, possibly including the addition of
further constraints used in determining whether or not an access is
permitted.
When the
checkPermission method of the AccessController is
invoked by the most recent caller (e.g., a method in the File
class), the basic algorithm for deciding whether to allow or deny
the requested access is as follows.
Therefore, the algorithm for
checking permissions is currently implemented as "lazy
evaluation". Suppose the current thread traversed m callers, in
the order of caller 1 to caller 2 to caller m. Then caller m
invoked the checkPermission method. The basic
algorithm checkPermission uses to determine whether
access is granted or denied is the following (see subsequent
sections for refinements):
i = m;
while (i > 0) {
if (caller i's domain does not have the permission)
throw AccessControlException
else if (caller i is marked as privileged)
return;
i = i - 1;
};
That is, a caller can be marked as
being "privileged" when it calls the doPrivileged
method. When making access control decisions, the
checkPermission method stops checking if it reaches a
caller that was marked as "privileged" via a
doPrivileged call without a context argument (see a
subsequent section for information about a context argument). If
that caller's domain has the specified permission, no further
checking is done and checkPermission returns quietly,
indicating that the requested access is allowed. If that domain
does not have the specified permission, an exception is thrown, as
usual.
The normal use of the "privileged" feature is as follows:
If you don't need to return a value from within the "privileged" block, do the following:
somemethod() {
...normal code here...
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// privileged code goes here, for example:
System.loadLibrary("awt");
return null; // nothing to return
}
});
...normal code here...
}
PrivilegedAction is an interface with
a single method, named run, that returns an Object.
The above example shows creation of an anonymous inner class
implementing that interface; a concrete implementation of the
run method is supplied. When the call to
doPrivileged is made, an instance of the
PrivilegedAction implementation is passed to it. The
doPrivileged method calls the run method
from the PrivilegedAction implementation after enabling privileges,
and returns the run method's return value as the
doPrivileged return value, which is ignored in this
example.
(For more information about inner
classes, see the Inner Classes Specification at
http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclasses.doc.html
or Nested Classes at
http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
.)
If you need to return a value, you can do something like the following:
somemethod() {
...normal code here...
String user = (String) AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
return System.getProperty("user.name");
}
}
);
...normal code here...
}
If the action performed in your
run method could throw a "checked" exception (one
listed in the throws clause of a method), then you
need to use the PrivilegedExceptionAction interface instead of the
PrivilegedAction interface:
somemethod() throws FileNotFoundException {
...normal code here...
try {
FileInputStream fis = (FileInputStream)
AccessController.doPrivileged(
new PrivilegedExceptionAction() {
public Object run() throws FileNotFoundException {
return new FileInputStream("someFile");
}
}
);
} catch (PrivilegedActionException e) {
// e.getException() should be an instance of
// FileNotFoundException,
// as only "checked" exceptions will be "wrapped" in a
// <code>PrivilegedActionException</code>.
throw (FileNotFoundException) e.getException();
}
...normal code here...
}
Some important points about being
privileged: Firstly, this concept only exists within a single
thread. As soon as the privileged code completes, the privilege is
guaranteed to be erased or revoked.
Secondly, in this example, the body
of code in the run method is privileged. However, if
it calls less trustworthy code that is less privileged, that code
will not gain any privileges as a result; a permission is only
granted if the privileged code has the permission and so
do all the subsequent callers in the call chain up to the
checkPermission call.
For more information about marking
code as "privileged," see
http://java.sun.com/j2se/sdk/1.2/docs/guide/security/doprivileged.html.
AccessController.checkPermission was called inside the
new thread, a security decision would be made based solely upon the
new thread's context, not taking into consideration that of the
parent thread.
This clean stack issue would not be a security problem per se, but it would make the writing of secure code, and especially system code, more prone to subtle errors. For example, a non-expert developer might assume, quite reasonably, that a child thread (e.g., one that does not involve untrusted code) inherits the same security context from the parent thread (e.g., one that involves untrusted code). This would cause unintended security holes when accessing controlled resources from inside the new thread (and then passing the resources along to less trusted code), if the parent context was not in fact saved.
Thus, when a new thread is created,
we actually ensure (via thread creation and other code) that it
automatically inherits the parent thread's security context at
the time of creation of the child thread, in such a way that
subsequent checkPermission calls in the child thread
will take into consideration the inherited parent context.
In other words, the logical thread
context is expanded to include both the parent context (in the form
of an AccessControlContext, described in the next section) and the
current context, and the algorithm for checking permissions is
expanded to the following. (Recall there are m callers up to the
call to checkPermission, and see the next section for
information about the AccessControlContext
checkPermission method.)
i = m;
while (i > 0) {
if (caller i's domain does not have the permission)
throw AccessControlException
else if (caller i is marked as privileged)
return;
i = i - 1;
};
// Next, check the context inherited when
// the thread was created. Whenever a new thread is created, the
// AccessControlContext at that time is
// stored and associated with the new thread, as the "inherited"
// context.
inheritedContext.checkPermission(permission);
Note that this inheritance is
transitive so that, for example, a grandchild inherits both from
the parent and the grandparent. Also note that the inherited
context snapshot is taken when the new child is created, and not
when the child is first run. There is no public API change for the
inheritance feature.checkPermission method performs security checks within
the context of the current execution thread (including the
inherited context). A difficulty arises when such a security check
can only be done in a different context. That is, sometimes a
security check that should be made within a given context will
actually need to be done from within a different context.
For example, when one thread posts an event to another thread, the
second thread serving the requesting event would not have the
proper context to complete access control, if the service requests
access to controller resources.
To address this issue, we provide
the AccessController getContext method and
AccessControlContext class. The getContext method
takes a "snapshot" of the current calling context, and places it in
an AccessControlContext object, which it returns. A sample call is
the following:
AccessControlContext acc = AccessController.getContext();This context captures relevant information so that an access control decision can be made by checking, from within a different context, against this context information. For example, one thread can post a request event to a second thread, while also supplying this context information. AccessControlContext itself has a
checkPermission
method that makes access decisions based on the context it
encapsulates, rather than that of the current execution thread.
Thus, the second thread can perform an appropriate security check
if necessary by invoking the following:
acc.checkPermission(permission);The above method call is equivalent to performing the same security check in the context of the first thread, even though it is done in the second thread.
There are also times where one or
more permissions must be checked against an access control context,
but it is unclear a priori which permissions are to be checked. In
these cases you can use the doPrivileged method that
takes a context:
somemethod() {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// Code goes here. Any permission checks from
// this point forward require both the current
// context and the snapshot's context to have
// the desired permission.
}
}, acc);
...normal code here...
Now the complete algorithm utilized by
the AccessController checkPermission method can be
given. Suppose the current thread traversed m callers, in the order
of caller 1 to caller 2 to caller m. Then caller m invoked the
checkPermission method. The algorithm
checkPermission uses to determine whether access is
granted or denied is the following
i = m;
while (i > 0) {
if (caller i's domain does not have the permission)
throw AccessControlException
else if (caller i is marked as privileged) {
if (a context was specified in the call to doPrivileged)
context.checkPermission(permission);
return;
}
i = i - 1;
};
// Next, check the context inherited when
// the thread was created. Whenever a new thread is created, the
// AccessControlContext at that time is
// stored and associated with the new thread, as the "inherited"
// context.
inheritedContext.checkPermission(permission);
