Should JAAS be renamed to JAS?

[Peter Firmstone]

Should JAAS should be renamed JAS?   Java will no longer have support 
for Authorization functionality, so this should be named "Java 
Authentication Service" JAS right?

I'm currently working on a new Authorization framework for Java, it 
works a little differently.

https://github.com/pfirmstone/HighPerformanceSecurity

A flaw in Java's authorization implementation, was if SecurityManager 
was enabled, privileges were turned on by default.   What do I mean?  An 
example may help:

For a developer to enable the use of a logged in Subject's Principal's, 
they had to ensure that a CodeSource wasn't granted those permissions.  
Often policy files granted AllPermission to known CodeSources, so how 
could the developer easily restrict permissions to Subjects?

Another problem was the Runnable interface was created in Java 1.0, 
prior to the security infrastructure in Java 1.2, so while a Thread's 
AccessControlContext could be recorded at the time of it's creation, 
Runnable tasks didn't have their AccessControlContext recorded at their 
time of creation, it would have worked if they were abstract classes...

Instead Authorization::privilegedCall overloaded methods accept a 
Callable parameter.   The Callable parameter is decorated, and when 
guards perform their checks, the stack walk only captures the domains on 
the stack, back to the decorator.   The domain of the caller is also 
recorded and stored in the decorator.

Basically, when a privilegedCall is made, the caller is requesting to 
use the privileges it has.   If no privileged call has been made, then 
no privileges are enabled, to reduce the attack surface area.

Additionally, another method Authorization::getSubjectAuthorization, 
returns an Authorization containing an unprivileged CodeSource domain, 
containing the Subject's principals, such that only the privileges of 
the Subject will be used to determine permissions.   Developers will use 
this method for data parsing (XML, deserialization, query's and 
scripts), this ensures that the decision to parse data will depend on 
how trustworthy the source of that data is.

Additionally there are these two methods:

Authorization::privilegesOn and Authorization::privilegesOff

Library code with Executor's that cannot be wrapped, need a way to be 
granted privileges.

These methods allow activating privileges for domains.

How do these methods work?

If there are no privilegedCall's in a Thread's stack, but all domains on 
the stack have their privileges turned on, then it will be treated as a 
privilegedCall, allowing guard checks to proceed.

Another improvement is a significant reduction in the size of the 
trusted codebase:

                 CodeSource cs = t.getCodeSource();
                 if (cs == null){ // Bootstrap ClassLoader?
                     Module module = declaringClass.getModule();
                     if (module.isNamed()){
                         try {
                             cs = new CodeSource( new URL("jrt:/" + 
module.getName()), (Certificate[]) null);
                         } catch (MalformedURLException ex) {
Logger.getLogger(Authorization.class.getName()).log(Level.SEVERE, null, ex);
                         }
                     }
                 }

In JGDMS, we have a POLP policy file generation tool, so we will need to 
do something similar here.

In Java's API we will need to instrument network and file access, among 
other things.

There is of course the problem of capturing the intent of 
AccessController::doPrivileged methods in the Java platform and existing 
code, we would like to preserve as many of these call as possible, so 
that we can capture the developers original intent of performing a 
privileged call.

Q: Why capture AccessController::doPrivileged calls?

A: Viral Permissions, we need to minimise the sections of code that 
require privileges and to reduce the amount of code that requires 
auditing, to be more targeted.

Once the JVM is instrumented, guards can be changed, but we have no 
plans to allow security to be turned off, instead tools will be provided 
to generate least privilege policies.  Think of it like a recording 
mode, where we record everything privileged the software needs to do, 
then everything that isn't necessary is switched off.

-- 
Regards,
  
Peter