river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject SVN Merge
Date Tue, 10 Jan 2012 06:24:06 GMT
The new security manager and policies are almost ready to merge back into trunk.

Any svn merge tips would be much appreciated.

First, I'd like to move some policy implementation classes that are at present public in org.apache.river.*,
into package private net.jini.* namespaces, to reduce the public api.

Not all of the code will be included, classes, like ConcurrentPermissions (and all policy
cache associated classes), even though far better than Permissions, will be discarded, as
recent developments (eliminating policy cache) have made them redundant.

DelegatePermission is still there, designed to work with delegate wrapper classes that encapsulate
sockets and and file handles, to enable removal of temporarily granted permissions. 

Example: A downloaded proxy is granted a SocketPermission to contact its server, if during
deserialisation, the proxy modifies some public static fields (java.xml.* vulnerabilities
ring a bell?) by replacing some platform classes with its own, it leaves some of its own proxy
code on the stack context.  The proxy after being downloaded is found to be untrusted and

Every time the object the proxy has injected into the platform is accessed, it steals information
and sends it back to its originating host.

If a DelegatePermission(SocketPermission p) is granted instead, the proxy recieves a socket
that denies access when the permission is revoked, when trust can't be verified.

The proxy could still perform a denial of service, by causing an out of memory error during

DelegatePermission can also be used to grant temporary or limited access to Principals, eg
after downloading 1GB, downloads are revoked and regranted at the next monthly cycle, something
sililar could be used to limit writes to the file system.

Obviously you'll need to buffer the input or output streams, to balance how often checks are
performed, that is, if you choose to utilise it.

A DelegateSocketFactory that can be used to encapsulate existing SocketFactory's will be released
at a later date to enable DelegatePermission controlled streams and channels.  Note any ProtectionDomains
with SocketPermission will still have access to the same channel.  

DelegatePermission is intended to be a dynamically or runtime granted Permission.

To function it requires a DelegateSecurityManager, each stack context domain must have permission
either for the DelegatePermission or it's representative Permission.

This was one motivation for a securitymanager cache, it needed to be as fast as possible and
non blocking, unlike policy cache.

Using delegates is of course optional.

The other thing I was toying with was using deny as well as grant in policy files:

Where denials would be checked first by the policy prior to checking grants:

So you could deny a proxy access to the local network, whilst granting it access to the entire
internet, with two simple policy statements.

Or you could allow access to a directory, but deny access to a user policy file contained
in that directory, for principal based grants.

The syntax would be identical to a grant statement in policy files, except deny replaces grant.

But then I realised despite the advantages, it adds complexity, because the deny statement
could have unintended scope narrowing / widening consequences and Permissions like SocketPermission
don't work as well as intended, it would be simpler to dynamically grant Permissions on an
as needed basis.

So any last remaining traces of deny must be removed.

Instead of using deny in policy grants, I figure that proxy's can optionally include permissions.perms
files under META-INF in their jar files as a hint to clients. By using the least priviledge
model and limiting the GrantPermissions given to Principals administrators can limit Permissions
users can grant to proxy's. 

The proxy developers would need to be aware they might not be granted all the permissions
they'd like and offer reduced functionality by catching SecurityException.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message