bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Lee <>
Subject Re: Refactoring BVal's use of privileges
Date Tue, 03 Apr 2012 19:40:30 GMT

Thanks for spending the time looking and improving the Java 2 security
aspects of BVal. It is good to standardize the security invocation
mechanism to avoid security exposures.

While I agree the overall approach and design, I am very hesitated to
introduce a new BValPermission as a gate to downstream security check.

- In theory, the doPriv is a mean for feature (BVal) to provide a security
QoS for an application to trust its implementation without specifying and
interrogating the security permissions of its caller. In JSE mode, the appl
execution still needs to provide the policy file with the permissions of
BVal and its depending packages and in JEE mode, application server
typically grants permissions to the packages it supports, therefore
additional BVal specific permission just adds another configuration
dependency without added value. May be I am missing something here.

- Compatibility to previous releases.  We have products shipped with
0.3/0.4-incubating releases and it is important to be compatible unless it
is really necessary, like spec compliant.

- Java 2 security is not a widely used features, let's keep it simple,
perform and clean.

Albert Lee.

On Mon, Apr 2, 2012 at 3:09 PM, Matt Benson <> wrote:

> 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 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
> .  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

Albert Lee.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message