bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: Refactoring BVal's use of privileges
Date Wed, 04 Apr 2012 09:44:21 GMT
+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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message