[jboss-as7-dev] More Security Stuff: Privileged Actions

[David M. Lloyd]

Some of you may have noticed my recent patch [1] to the AS which factors 
out a couple hundred privileged blocks into 20 or so common classes.  I 
plan to do more such factoring, but I want to talk a little bit about 
what privileged actions are all about first.  This isn't just an 
introductory text - I also want to get the more experienced folks 
thinking about privilege in a new way.  For the subject matter review, 
read my previous email "On security contexts and propagation".

There are essentially three different contexts we need to consider here:

1) Privileged context - the method is definitely only ever invoked from 
other known-to-be-privileged context
2) Maybe privileged context - the method in question might be called 
from user code, or it might be called from privileged code
3) Unprivileged context - the method in question is intended to be 
invoked from user deployment code and there is a high degree of 
certainty that the caller is unprivileged

Those of us who are already security-aware often have the automatic 
reaction of putting absolutely everything that requires privileges into 
doPrivileged constructs.  But, this is a practice we should definitely 
reexamine.  Calling through doPrivileged is not free, and the GC 
pressure resulting from all the temporary objects have a real cost as 
well.  In addition, the anonymous classes which often accompany these 
actions cause class loading time to increase and permanent generation to 
be consumed for actions which are often duplicated in many places.

If you're writing a method that is known to run in a privileged context 
already, you do not in fact need any doPrivileged at all.  This should 
include methods in DUPs, extensions, management operations, thread 
pools, and (most) interceptors.

Most framework API methods fall under the categories of #2 or #3. 
Methods of this type should be subjected to the following question: 
Does this method allow the caller to perform one or more actions which 
they would not otherwise be authorized for?

If the answer is "yes", then you usually need two things: a privileged 
block to execute the action (of course), and a permission check to make 
sure the caller has permission to take the given action.

It may seem like the second is redundant: what is the purpose of taking 
away one permission check and adding another?  It is often the case that 
an operation is very specific in purpose, but requires several 
permissions in order to run.  It also may be the case that granting the 
unprivileged caller the full set of required permissions will give them 
an undesirable level of access; in these cases it is wise to grant the 
caller a narrow permission with a single purpose, which is checked for 
in the privileged context.

As a final consideration, there are often cases where the privileged 
action is encapsulated by an already existing object.  In some cases, 
you can simply have your object directly implement PrivilegedAction or 
PrivilegedExceptionAction, thus allowing doPrivileged to call directly 
into your object without having to instantiate an anonymous class.  See 
[2] for an example of this - by having InterceptorContext implement 
PrivilegedExceptionAction we're able to reuse an already-existing object.

Going forward I would like to see better documentation - especially on 
API methods - about what the security requirements and effects are for a 
given method.  More on this in the future.

[1] https://github.com/jbossas/jboss-as/commit/8ca603eb9d
[2] https://github.com/dmlloyd/jboss-invocation/commit/b654b48cbb79

-- 
- DML