bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Refactoring BVal's use of privileges
Date Mon, 02 Apr 2012 20:09:25 GMT
Hi all,
  It has been an ongoing goal that BVal be able to operate in a
secured environment.  I myself have been guilty of causing breakages
in this regard due to my own ignorance of Java security.  We've
accepted submissions of code that attempted to help us shore up our
security (BVAL-92), followed by commits that reintroduced security
holes.  In the interest of ensuring future security, I have added a
policy file to run with the bval-jsr303 testsuite and a profile to
enable it.  While learning enough about Java security to create the
policy file such that it would allow us to run our tests with a
SecurityManager, I came to understand more about some of our
privileged APIs:

 - BVal contained utility methods to conditionally run
Privileged[Exception]Action using AccessController in the presence of
a SecurityManager, directly in its absence.  However, providing public
methods to do such is considered a security hole because third-party
code can use these methods to execute arbitrary code with BVal's
privileges.
 - not providing these methods results in a lot of noisy code
duplication for each class potentially needing to make privileged
calls:  if securityManager present AccessController.run(X) else X.
Additionally our utility code must create only the action objects, and
the calling code must then engage in a lot of repetitive exception
handling.

I have committed my attempt at a compromise solution to
https://svn.apache.org/repos/asf/bval/branches/privileged .  Its
highlights:

Instead of static utility methods, I have created an object whose
instances can execute arbitrary Privileged[Exception]Actions,
org.apache.bval.util.Privileged.  This class also provides convenience
calls equivalent to those formerly provided by
org.apache.bval.util.PrivilegedActions (with the exception of some
unused methods).  org.apache.bval.jsr303.util.Privileged extends the
core class and provides calls equivalent to those provided by
org.apache.bval.jsr303.util.SecureActions.

In order to make this design secure, these calls must be made only by
code with certain privileges.  The code in the branch accomplishes
this by defining a custom permission, org.apache.bval.BValPermission,
and in the interest of performance the permission is checked only when
an instance of org.apache.bval.util.Privileged is constructed.
Typical consumer code will then define a private static final instance
of this class; the permission is therefore consulted only once (not at
all in the absence of a SecurityManager).  In this way we can do our
privileged calls using public methods, yet still give the user a means
of securing calls to them.

The biggest caveat to all this is that the changes are not binary
compatible with previous versions of BVal.  In my opinion, this is not
a large concern for several reasons:

1.  BVal has still not released a 1.0 version.  IMO our APIs are not
set in stone until that point.
2.  BVal is primarily a Bean Validation implementation and is
therefore most commonly used via the javax.validation APIs.  These
are, of course, unaffected.  Users of BVal in secure environments will
typically just have to grant BValPermissions to a few codeBases (the
Bean Validation API and the BVal jars).
3.  BVal 0.4 will include the changes to PathImpl that represent a
complete breaking incompatibility between Bean Validation
implementations that pass TCK v<=1.0.4.GA and v>= 1.0.5.GA and is
therefore not really binary compatible anyway.

If we can agree on the security/usability of my approach to the
privilege APIs, as well as my rationale wrt binary incompatibility, I
would like to commit these changes to trunk.

Matt

Mime
View raw message