Probably a stupid question, the benefit of policy files?

[Rick Reumann]

It seems like if you are relying on a policy file to define security for a client application, isn't this a bad idea? For example, if your client app starts up with a shell script that has a jvm arg:

-Djava.security.policy=./dir/my.poilcy

A user could modify this file or simply modify the script and swap out the policy file with their own and open up all permissions? - just have one grant entry: permission java.security.AllPermission; ?

[Ulf Dittmer]

The theory is that the user is in charge of his own machine (and is trusted to do the right thing), whereas the application by default is not. If the user feels that the application can be trusted, he can allow it to do more things than an untrusted application. Since that requires a conscious act of the user, that is considered OK.

This is similar to signed applets, where a user is shown the applet certificate. He can accept it (and thus grant the applet additional permissions), or reject it (thus preventing the applet from acquiring those permissions).

[Rick Reumann]

Originally posted by Ulf Dittmer:
The theory is that the user is in charge of his own machine (and is trusted to do the right thing), whereas the application by default is not. If the user feels that the application can be trusted, he can allow it to do more things than an untrusted application. Since that requires a conscious act of the user, that is considered OK.

I figured as such, but it does seem to create an interesting situation when it comes to authorization. I'll explain the approach I opted for at the end of this post, but I'll start with the 'problem.' (Some of this in another post, but I'm going to link to this one from that post.)...

Let's assume the user installs his company's Java swing application on his machine. We'll assume this client application has a direct connection to the internet as well (ignoring off-line mode.)

The developers of the application know about JAAS and figure they should use that to help enforce what things the user could do within the client app.

Authentication works nicely by pulling the user's windows username and cert and doing an online check to get possibly a list of roles the user has.

The developer now wants to implement authorization checks on various parts of his client app. For example maybe only an "Amdin" role could perform an "edit" function. An easy non-jaas approach is to simply let the developer of the client hard code logic into the application, looking up a role and then allowing it.. ie...

if ( loggedInUser.hasRole("AMDIN") ) {
//allow him to call editSomething()
}

The above might be an ok approach, but the developers want to use JAAS and call:

Subject.doAsPrivileged(subject),
    new PrivilegedExceptionAction() {
        public Object run() {
            AccessController.checkPermission(new FooBarPermission("someOperation","edit"));
            return null;
        }
    }, null);

So the question now comes up as to where to store the allowable Permissions for user roles.

Let's assume we want to use a policy file. Obviously for this approach to work, we'd have to make sure the application comes installed with a custom file policy that declares all the role permissions. We also have to make sure the user can't modify this file, for if he could, he could grant himself "AllPermissions." We also have to make sure there is no way that the user can start up the application passing in his own policy file as an arg and bypassing our policy file. We also have to make sure he can't disable using a SecurityManager. For example, we'd be in trouble if we only relied on an editable startup script that passed in the args for the securityManager and the policy file (since the user could just remove or replace them as they wish.)

Here's the overall approach I ended up with....

1) Do not rely on any security args being passed in to start your application.

2) Create a policy file and bundle it in your jar. The policy should grant AllPermissions. (Considering the client is
trusting you application to install on the machine, this isn't that big of a deal.)

3) Create your config file that declares your Login module and bundle that in your jar as well.

4) Create your own Permission class to handle what you want to authorize.

5) Create your own Policy class or your own Security Manager to work with the Permsission class you created. If you create your own Policy you won't need
to rely on a policy file and can ensure that your test in the implies method of the Policy file really checks for Permssions that you can manually give to the user/codeSource. (Without a custom Policy or SecurityManager, there might be a hole where somehow the user managed to pass a policy file that granted AllPermissions.
We only have our policy file (with AllPermissions) around just so that we can pass through any Permissions we don't care about to be handled by the default Policy.

6) Load your policy and config files from your jar and then initialize your Policy and the default or custom SecurityManager (in this example I'm showing a custom Policy and using the default SecurityManager). I do this in a static block. It should be in a class that first gets loaded. This is nice also since it also forces a SecurityManager to be used - and doesn't rely on passing in the securityManager arg by command line.

static {
    URL policyURL = new PWCLogin().getClass().getResource("/conf/myJAAS.policy");
    System.setProperty("java.security.policy", policyURL.toString());
    URL configURL = new PWCLogin().getClass().getResource("/conf/myJAAS.config");
    System.setProperty("java.security.auth.login.config", configURL.toString());
    MyPolicy myPolicy = new MyPolicy(Policy.getPolicy());
    Policy.setPolicy(myPolicy);
    System.setSecurityManager(new SecurityManager());
}

My Policy looks something like...

 
public class MyPolicy extends Policy {
Policy defaultPolicy;
 
public MyPolicy(Policy p) {
defaultPolicy = p;
}
 
@Override
public PermissionCollection getPermissions(CodeSource cs) {
PermissionCollection pc = defaultPolicy.getPermissions(cs);
        //load in your Permissions for the user...
pc.add(new MyCustomPermission("Foobar"));
return pc;
}
 
@Override
public void refresh() {
// TODO Auto-generated method stub
    }
 
@Override
public boolean implies(final ProtectionDomain domain, final Permission permission) {
PermissionCollection col =  getPermissions(domain);
if ( permission  instanceof MyCustomPermission ) {
 return ((MyCustomPermission)permission).implies(permission);
}  else { 
return super.implies(domain, permission); 
} 
}
}

[ August 16, 2007: Message edited by: Rick Reumann ]

[Tony Docherty]

Hi Rick, I think the problem you have with policy files is that you are trying to use them for the wrong thing. They are user centric not application centric ie policy files enable the user to control the level of access an application has to their system (as Ulf has already stated). They are not there so the application can set the features a particular user can access. This must be done (as you have implemented) in a file the user has no access to/no way of modifying.

[Pat Farrell]

Originally posted by Rick Reumann:
It seems like if you are relying on a policy file to define security for a client application, isn't this a bad idea?

Yes, its a bad idea.

Never rely upon the user for security. Never let a user control anything important. Store it somewhere else, a database, on the web, etc.

[Ulf Dittmer]

Originally posted by Rick Reumann:

It seems like if you are relying on a policy file to define security for a client application, isn't this a bad idea?

To which Pat Farrell responded:

Yes, its a bad idea. Never rely upon the user for security.

As Tony pointed out, we're talking about two different aspects of security here. One is to protect a users' computer from a malicious application; that's what policies and permissions are for, and policy files work fine for that. The other is to protect an application (and its associated data) from a user who may not be sufficiently authorized. As you discovered, policies and permissions are an awkward fit for that - JAAS is better suited, but may be overkill due to its complexity.