+1 for using the approach we have in owb. regards, gerhard
2012/4/3 Matt Benson <[email protected]> > Albert, > I don't see that we can provide publicly accessible methods like > PrivilegedActions.run() without guarding them in some way. Another > approach to guarding the constructor of a helper object such as I > propose would be inspecting the call stack, but that seems a little > clumsy to me, and in any case you must then find a mechanism for > declaring which classes are allowed to construct it (in OWB's case > there is only one such class). In my opinion using a permission > aligns perfectly with the subject at hand; the user quite obviously > has a policy file and is presumably accustomed to editing it. I am > open to a better way, but I haven't yet found a simpler one than > granting BValPermission "*" to a few codeBases, and since we only > check it during a constructor call, minimizing the number of calls > minimizes the performance impact. > > Thanks, > Matt > > On Tue, Apr 3, 2012 at 2:40 PM, Albert Lee <[email protected]> wrote: > > 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. >
