You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bval.apache.org by Matt Benson <gu...@gmail.com> on 2012/04/02 22:09:25 UTC
Refactoring BVal's use of privileges
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
Re: Refactoring BVal's use of privileges
Posted by Mark Struberg <st...@yahoo.de>.
+1 to discuss those changes after releasing 0.4
but also
+1 that we need to implement this somewhen ;)
We also have a similar functionality in OWB and have a 95% solution over there. And I have an idea already how to close the other 5% ;) Will elaborate after a bit fiddling...
LieGrue,
strub
----- Original Message -----
> From: Albert Lee <al...@gmail.com>
> To: dev@bval.apache.org; gudnabrsam@gmail.com
> Cc:
> Sent: Tuesday, April 3, 2012 9:40 PM
> Subject: Re: Refactoring BVal's use of privileges
>
> 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 <gu...@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.
>
Re: Refactoring BVal's use of privileges
Posted by Matt Benson <gu...@gmail.com>.
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
<ge...@gmail.com> wrote:
> +1 for using the approach we have in owb.
>
> regards,
> gerhard
>
>
>
> 2012/4/3 Matt Benson <gu...@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 <al...@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 <gu...@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.
>>
Re: Refactoring BVal's use of privileges
Posted by Gerhard Petracek <ge...@gmail.com>.
+1 for using the approach we have in owb.
regards,
gerhard
2012/4/3 Matt Benson <gu...@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 <al...@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 <gu...@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.
>
Re: Refactoring BVal's use of privileges
Posted by Matt Benson <gu...@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 <al...@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 <gu...@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.
Re: Refactoring BVal's use of privileges
Posted by Albert Lee <al...@gmail.com>.
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 <gu...@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.