river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Ease of use, development & deployment
Date Tue, 16 Aug 2011 08:52:07 GMT
What are the challenges writing secure java policy files?

   1. Determining a set of minimal permissions that code requires to
      execute, not only for local code but for proxy's too.
   2. Figuring out which Principal / CodeSource / Certificate,
      permission grant combinations to add to policy files.
   3. Maintaining policy files in a distributed environment.

Partial answer:

There's now a com.sun.jini.tools.ProfilingSecurityManager, it allows 
code to execute and prints out the permissions required for each 
codebase.  This can be run prior to deployment to assist in figuring out 
the implications of granting each permission and to whom they should be 
granted.

The ProfilingSecurityManager can also be used to determine the 
permission requirements of Proxy codebases.

I've got some plans to include a permissions requirement file in each 
proxy jar, in fact this could be done for all jar files.  This enables 
an easy runtime determination of the security requirements of each jar 
codebase.

A possible solution:

We could add a method to net.jini.security.Security to parse jar files 
for META-INF/permissions.perms declared permissions.

public CodeSource jarPermissions(CodeSource cs);

The returned class could be an overriding implementation of CodeSource, 
which overrides toString.

Now if we do this for all CodeSource's included in ProtectionDomain, 
when we get a SecurityException, the cause for each ProtectionDomain 
will include the list of Permission's required by the CodeSource along 
with those assigned to the ProtectionDomain's in the current context, 
then if we wrap thrown SecurityException's in a RemoteException for 
services, we know exactly why the SecurityException was caused.

When the SecurityException is thrown, the ProtectionDomain that fails 
prints out it's CodeSource, Principals and Permissions granted to it 
(including any from the policy), we'll just be adding a list of required 
permissions, so all the information is in one place.

This will make it easy for an administrator to quickly determine and add 
the missing permission to a user's profile, when required, using 
RemotePolicy.

That's all I'm going to discuss for now, so you can chew it over, I'll 
continue the thread later.

Cheers,

Peter.




Mime
View raw message