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 Wed, 04 Apr 2012 14:45:00 GMT
I don't think we can precisely use the OWB model--at least, not until
it is finished.  The analogous class in OWB is the
ManagedSecurityService, which is the implementation of SecurityService
that a user must configure to use OWB in a secured environment
(incidentally, this amount of custom config in OWB puts equal or
greater responsibility on the user compared to the BVal branch code,
IMHO).  The SecurityService instance is available by a public call
from WebBeansContext, an/the instance of which is *currently*
available to anyone who cares to call a (deprecated) public static
method.  Any potential ensuing problems are mitigated somewhat by the
fact that the SecurityService interface defines specific
privilege-requiring actions, which are fairly minimal (contrast the
trunk of BVal, wherein PrivilegedActions provides run() methods to run
arbitrary Privileged[Exception]Actions).  In any event, the OWB
approach is currently incomplete such there is not enough for BVal to
imitate.

We don't quite seem to have consensus yet, so for the time being I
will attempt to handle trunk with as minimal changes as possible so
that we can release 0.4.  But this discussion is far from over!  >;)

Matt

On Wed, Apr 4, 2012 at 4:44 AM, Gerhard Petracek
<gerhard.petracek@gmail.com> wrote:
> +1 for using the approach we have in owb.
>
> regards,
> gerhard
>
>
>
> 2012/4/3 Matt Benson <gudnabrsam@gmail.com>
>
>> 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