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
