More Security Stuff: Privileged Actions
by 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
13 years, 1 month
- 2
- 1
Security manager test runs
by David M. Lloyd
The AS codebase now supports running under a security manager. Well,
sort of. There are a few places where we need privileged blocks and/or
permission checks, but you can boot up AS under a security manager today
if you want. Just follow these steps:
1. Modify standalone.sh so that the -secmgr flag is passed in to JBoss
Modules.
Well, I guess there's just the one step. Anyway I've noticed that the
impact on startup time is not as bad as I had expected, which is good.
So the question is: Should we set up a security manager-enabled test
run? How should it work?
--
- DML
13 years, 1 month
- 4
- 3