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

[Anil Saldhana]

Some pointers on the doPriv stuff:
* The dopriv blocks are just ugly. I wish function pointers (closures 
???) existed in Java
such that we could have a single block of code that we could pass into a 
dopriv block in the
presence of a Java Security Manager. Now in the case of non-JSM, the 
code block has to exist
outside.

* In the core AS code, for every sensitive block of operation, we need 
to have a doPriv block. But
before that call, there needs to be a check that the caller has a 
particular permission. The doPriv block will inherit
the permissions we assign to JBossAS code.

* Applications do not need to bother about doPriv blocks as they can be 
provisioned in the security manager policy.

On 03/01/2013 10:45 AM, David M. Lloyd wrote:
> 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.
Right.  This needs to be enforced by the PR mergers.
>
> [1] https://github.com/jbossas/jboss-as/commit/8ca603eb9d
> [2] https://github.com/dmlloyd/jboss-invocation/commit/b654b48cbb79
>