+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... LieGrue, strub ----- Original Message ----- > From: Albert Lee <[email protected]> > To: [email protected]; [email protected] > 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 <[email protected]> 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 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 >> > > > > -- > Albert Lee. >
