For quite some time, I've been using a package that I put together which uses
XML to create an interface and a SecurityDelegate as you describe below. It was
embedded in one of my applications for some time, but a few years back, I pulled
it out into a separate codebase so that I could use it in several other projects
which had grown to need more granular security control.
I've put it out on authlib.dev.java.net. There really is not a lot of
documentation at this point. This is more or less a "throw it over the wall"
move.
Here's a summary of how it is used, and how it works.
It provides for the definition of users and groups/roles. There is a whole GUI
component to the code which allows editing. This data is access/stored using a
JDBC based backing store.
The class, org.wonderly.authlib.BuildAccess processes the XML file. There is a
sample XML file which shows most of what is possible, but the parsing in
BuildAccess is the real clue to what is possible.
There are object types, which you designate the type of permission that applies
to that object. An example from the access.xml in the CVS tree is:
<object type="view" access="update,read"
permission="PermissionTwo"/>
This says that there are parameters in method class which are "view" type
references. PermissionTwo is used to control access to those type objects. The
"access" attribute represents the types of permissions that the permission
implementation supports for its "access" parameter during construction.
A single method definition looks like the following:
<method return="String" name="getDBUnitView" qualifiers="public">
<descr>
This method is used to get the description of the named view.
</descr>
<security>
<filter access="read" filtered="view"
filteredType="String"
params="view" filterGeneric="String"
class="TestUpdateAuthFilter"/>
<!-- limit access="read" type="view" arg="view"/ -->
</security>
<args>
<arg name="view" type="String" descr="name of the view to get the definition
of"/>
</args>
<exceptions>
<throws name="SQLException" descr="when a database access error
occurs"/>
</exceptions>
</method>
The method signature and JavaDoc is generated from this definition.
The security section says that a filter operation should be performed to return
the value if it is accessible, instead of throwing an exception as <limit> does.
The class, TestUpdateAuthFilter performs the filtering operation. It implements
a standard interface to define how the filtering works.
Here's the generated code:
public String getDBUnitView( String view ) throws
java.rmi.RemoteException , SQLException {
// Check for required access rights.
String XXXval = null;
String XXXtype = "filter";
String XXXaccess = "read";
try {
// Call the method, authorization passes
// Get Initial data
String XXXlist = XXXacc.getDBUnitView( view );
UpdateAuthFilter<String> XXXfilt = null;
try {
XXXfilt = new TestUpdateAuthFilter<String>();
} catch( RuntimeException ex ) {
log.log( Level.SEVERE, ex.toString(), ex );
throw new AuthorizationException(
ex.toString(), ex );
}
String XXXret = XXXfilt.filterList( new Object[] {view},
XXXlist, "read", XXXauth, XXXdb );
secureLog( Level.INFO, "{0}[{1}]:
"+"getDBUnitView("+view+") ==> "+XXXret,
XXXauth.getUserName(), XXXaccess );
return XXXret;
} catch( RuntimeException ex ) {
// Make the exception source visible
log.log( Level.SEVERE, ex.toString(), ex );
// Rethrow it to stop the operation
throw ex;
}
}
There's a quite a bit more I can talk about and document, but I just wanted to
throw this out. It's licensed under the Apache license, but I did not put the
license into every source file, yet.
Gregg Wonderly
Peter Firmstone wrote:
Please help identify any fallacies or oversights in the following
arguments.
A Permission may be revoked, at any point in time after a revocation,
untrusted code may hold a reference to a privileged object.
Some Permission's protect methods, such as Thread.interrupt(), these are
effectively revoked with the existing Java security model, however other
objects are only protected in their constructor, the responsibility
being on the trusted code, not to let their references escape, such as
FileOutputStream.
The moment code holding a reference becomes untrusted, the reference has
escaped.
Instead of using a GuardedObject, or checking permission in
constructors, to deal with Permission's that can be revoked, we need to
encapsulate the object that needs protection with a SecurityDelegate.
During a checkPermission call, the current Thread's AccessControlContext
is obtained, and (gross simplification) is asked to checkPermission.
The AccessControlContext contains all the ProtectionDomain's on the
stack, all ProtectionDomains on the stack must have the Permission for
it to succeed. The ProtectionDomain's contained by the
AccessControlContext are related to the class and object methods called
and returned, the ProtectionDomain's are dynamically added or removed.
So the thinking behind the SecurityDelegate's private check method is
that an object must be protected in a dynamically changing environment:
1. Has the RevokeableDynamicPolicy advised that a check must be
performed?
2. Is this the same thread that the last security check was made
against? If we haven't been advised that there is a reduction of
trust in our dynamic Security environment and the last
checkPermission call succeeded on this thread, then we can assume
that this Tread is still safe.
3. If this thread is different or new, then we must checkPermission,
regardless of whether trust has changed recently or not.
The costs:
1. Multi-threading is penalised (although a WeakMap could be
utilised, with threads as keys, and boolean check values, where
all are set true by the notify() call).
2. The three "if" calls on every method invocation, check, null and
== Thread.
3. Replicating the check method on all implementers (this will
require a helper class to implement the check).
4. The RevokeableDynamicPolicy will need to notify all
SecurityDelegate's every time a reduction in trust occurs, it will
rely on GC to clean up and remove SecurityDelegates.
The assumption is if the current Thread was trustworthy last call and
the environment hasn't experienced a reduction of trust, we can still
trust this thread. There is of course a risk that a Thread may have a
new ProtectionDomain on it's stack that isn't trusted, however this
could still happen in the case of the guarded object, where the
environment doesn't experience a reduction of trust and the trusted code
must be trusted not to let the reference escape it's own
ProtectionDomain. Any code that experiences a reduction of trust will
receive an AccessControlException.
Cheers,
Peter.
Peter Firmstone wrote:
Tim Blackman wrote:
On Jul 31, 2010, at 11:53 PM, Peter Firmstone wrote:
<snip>
A RevokeableDynamicPolicy supports the addition or removal of
PermissionGrant's
<snip>
Hmmm.
I remember talking with Bob and Mike Warres about this. The problem
with removing permission grants is that when code is granted a
permission, it can very likely squirrel away something -- an object,
or another capability available through the granted permission --
that will permit it to perform the same operation again without the
JVM checking for the permission again. Our conclusion was that there
was probably no effective way to implement removal of permission grants.
Perhaps there is something about the particulars of what you have
done here to negate this argument -- and I have not had the time to
check the details of your stuff myself to be sure -- but my guess is
that it will be difficult or impossible to do this in an airtight
manner.
First I'd better point out that this is still an experiment and may
not make a release, but I'm glad you've responded, as security is a
difficult issue and all help is appreciated.
The SecurityDelegate's I mentioned earlier, are of course a
compromise, many existing security guards on existing Java classes are
on constructors or methods that return object's, however object's such
as OutputStream and the likes, have unguarded methods, so once these
objects have been released, the reference can be stored, by what may
later become untrusted, and the methods called by untrusted objects.
The SecurityDelegate is a wrapper class that implements the same
interface as the guarded object, but once notified of a Permission
revocation ensures the next thread to access the guarded object,
through the SecurityDelegate has AccessController.checkPermission
called again.
Because of the cost of the Permission check, it's too expensive to
call on every method invocation.
However there is still a flaw in this, consider for a moment an object
protected by a SecurityDelegate, permission's are revoked, the policy
notifies all SecurityDelegate's of a revocation, they ensure the next
method call rechecks permission. The flaw is that once the
SecurityDelegate, containing the protected object is in untrusted
hands, we don't know how many references to it exist. The next call
might have permission, however there is no guarantee that another
following will. The mixing of untrusted and trusted code is the risk.
While it cannot be eliminated entirely, every method requiring
protection, should execute a private method something like the
following (Constructors and methods excluded for clarity):
class ProtectedOutputStream extends OutputStream implements
SecurityDelegate {
private final OutputStream protected;
private volatile boolean check = true;
private volatile Thread currentThread = null;
public void notify(){
check = true;
}
private void check(){
if ( check == true) {
AccessController.checkPermission(perm);
currentThread = Thread.currentThread();
check = false;
return;
}
if ( currentThread != null ) {
if (Thread.currentThread() == currentThread ) {
return;
}
}
AccessController.checkPermission(perm);
currentThread = Thread.currentThread();
return;
}
public void write(byte[] b) {
check();
protected.write(b);
}
}
Still, I'm not sure if this is enough to protect the object, there are
some Thread timing issues I've ignored here, but those aside, I don't
want to call the AccessController every invocation, for obvious
efficiency reasons.
Thought's and ideas?
Cheers,
Peter.
