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
