bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: Refactoring BVal's use of privileges
Date Tue, 03 Apr 2012 19:48:14 GMT
+1 to discuss those changes after releasing 0.4

but also 

+1 that we need to implement this somewhen ;)

We also have a similar functionality in OWB and have a 95% solution over there. And I have
an idea already how to close the other 5% ;) Will elaborate after a bit fiddling...


----- Original Message -----
> From: Albert Lee <>
> To:;
> Cc: 
> Sent: Tuesday, April 3, 2012 9:40 PM
> Subject: Re: Refactoring BVal's use of privileges
> Matt,
> 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.

View raw message