bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: Refactoring BVal's use of privileges
Date Tue, 03 Apr 2012 19:56:15 GMT
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 <allee8285@gmail.com> 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 <gudnabrsam@gmail.com> 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.

Mime
View raw message