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
discarded.
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 deserialisation.
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.
Regards,
Peter.
