JAAS - malicious subject and principal creation - security

Question

I'm a newbie to JAAS and I still can't get one thing: what if a malicious user creates the subject and principal manually ?
Shouldn't there be some validation of subject/principal in case the user has tampered with it ? None of the tutorials I've seen even mentions this.
Look at this example (ch02 from jaasbook.com):
SimpleCallbackHandler cb = new SimpleCallbackHandler(username,
password);
LoginContext ctx = new LoginContext("chp02", cb);
ctx.login();
Subject subject = ctx.getSubject();
System.out.println("Logged in " + subject);
Subject.doAsPrivileged(subject, new PrivilegedAction() { ...
And if I replace this code with this one:
Subject subject = new Subject();
Principal p = new SysAdminPrincipal(username);
subject.getPrincipals().add(p);
Subject.doAsPrivileged(subject, new PrivilegedAction() { ...
it works just as well (at least in this sample code).
I must have missed sth obvious otherwise it would make no sense to use jaas at all.
Thanks

Answer 1

The distinction is between trusted and untrusted code.
If you allow code to run within the JVM that you do not trust then you need to protect the JVM with a configured Policy and running with a SecurityManager enabled. This is akin to the Java Applet environment. Within such an environment you will typically lock down parts of the codebase such that only code from trusted sources, and optionally cryptographically signed, can run, or call, other parts of code.
Within Java security, when a permission check is made the entire calling stack is checked to ensure that every part of the stack is allowed to use the permission.
In this case, you are starting a PrivilegedAction which associates a Subject to the AccessControlContext. If you look into the sourcecode you'll see that performs a permission check:
javax.security.auth.AuthPermission "doAs";
In the default Java security policy, the only code which can do this are installed Java extensions, so if you want to do this in your own code, with a running SecurityManager, you will need to manually set this permission.
So, the Subject class is unprotected because it is of no affect unless its associated with an AccesssControlContext.
The AccesssControlContext is protected by an AuthPermission.
The setting of AuthPermission is protectectd by the security Policy and SecurityManager, which are configured at JVM startup.
In this case, if you run with no SecurityManager, or a custom Policy which grants an AllPermission to any codebase, and you allow untusted code to run, then you have a big security problem.
If you want to run untrusted code and assign Subjects to AccessControlContexts then protect the code which does this will something like the following policy file:
grant codebase "file://home/me/myapp.jar" signedby "me" {
javax.security.auth.AuthPermission "doAs";
}
This protects that only your codebase, including the call stack, can perform the Subject assignment.
Or just make sure that you trust the code you deploy to your app...this is the 99% deployment scenario where most applications are protected within their host environment and do not allow remote code to be executed.