Working with security policy (was: Re: [jira] Commented: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.)

["David W. Van Couvering" <Da...@Sun.COM>]

When I was doing the classloader work, I had to grant permission to the 
Derby codebase to be able to do classloader-related work 
(createClassloader, accessClassInPackage.sun.reflect, getClassloader, 
getProtectionDomain).

How do I know whether granting a certain permission is shadowing a "bug" 
versus the right thing to do?  I suspect what you want is as refined a 
policy as possible -- granting only the necessary permissions to the 
necessary jar file(s).

Also, if I need to grant new permissions, as above, what documentation 
do I need to change.  Where is the "default policy file" that we ship to 
users (or does such a file not yet exist), as I would obviously need to 
modify this...  Is derby_tests.policy being used as a template for this?

Thanks,

David

> 
> 
>>How should I fix this?  Should I edit a policy file or make a comment
>>to why it is disabled?
> 
> 
> Depends on why it is failing. Adding policy file entries to work around
> bugs is most likely a bad idea, it can hide other security bugs. If it's
> the same reason as the other backup failures then add a comment with the
> bug number. If it's a different reason then a new Jira bug report should
> be entered and a comment to reflect that.
> 
> 
>>A related question: How is Derby users supposed to deal with this?  It
>>seems like it would create some hassle for them to run with the
>>SecurityManager.
> 
> 
> Someone has to have the itch to fix the bug, otherwise it's broken for
> the user.
> 
> It would be great for all the bugs I've found during this effort to be
> fixed in the next release, I don't have time to fix them all.
> 
> http://wiki.apache.org/db-derby/SecurityManagerTesting
> 
> Thanks,
> Dan.
> 

Re: Working with security policy

[Daniel John Debrunner <dj...@apache.org>]

Kathey Marsden wrote:

> I  think you are right that  new functionality might indeed need to 
> require new permissions, but existing tests and functionality should run
> with the currently documented permissions.  I am not sure what
> functionality your classloader work adds, but tests for the new product
> functionality might reasonably require new permissions.  Existing tests
> should just work with the currently  documented permissions. 

To catch regressions as you describe we would need to modify the test
harness to allow tests to have specific permissions granted to them.
Then the single test policy we have now would be required permissions
for Derby (e.g. property reads, class loader for embedded) and then the
_app.properties file for a test would add in selected permissions.

That would be a great improvement, a step up from the current testing,
where the set of permissions granted to a Derby jar is the union of all
permissions required for all tests.

Dan.

Re: Working with security policy

[Kathey Marsden <km...@sbcglobal.net>]

David W. Van Couvering wrote:

>
> Well, that doesn't seem completely fair.  If I am adding new, valuable
> functionality that requires new permissions, I think it's reasonable
> to add them to the list.  How would I get my classloader work in, for
> instance?
>
I  think you are right that  new functionality might indeed need to 
require new permissions, but existing tests and functionality should run
with the currently documented permissions.  I am not sure what
functionality your classloader work adds, but tests for the new product
functionality might reasonably require new permissions.  Existing tests
should just work with the currently  documented permissions.   I  don't
think internal improvements like code sharing infrastructure could 
justify requiring  permissions that Sun describes as "extremely
dangerous" across the board. 

http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html


Kathey

Re: Working with security policy

["David W. Van Couvering" <Da...@Sun.COM>]

I think I need to write up something explaining what I am doing with 
classloaders that you all can look at and review.  But that's 
back-burnered right now until I can get the client code 
internationalized, that's a bigger itch for "me" right now :)

David

Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
> 
> 
> 
>>>>When I was doing the classloader work, I had to grant permission to
>>>>the Derby codebase to be able to do classloader-related work
>>>>(createClassloader, accessClassInPackage.sun.reflect, getClassloader,
>>>>getProtectionDomain).
> 
> 
> If there's a good justification for a permission then it's fine to make
> Derby dependent on it. From a high level view of what you are doing I
> would have concerns about Derby code needing
> accessClassInPackage.sun.reflect, getClassloader and
> getProtectionDomain. Esepecially the one with sun.reflect, isn't that
> granting internal access to a class of a specific VM implementation?
> 
> I look at the problem from the view of someone who is running Derby on
> behalf of a third-party application on their own machine. What minimal
> set of permissions do they have to grant to Derby? What's the
> explanation for those permissions? Can they feel comfortable running
> such an application with the permissions granted?
> 
> If we said Derby has to be granted permission to read all files, read
> and write all system properties, etc. then Derby would not be attractive
> in those situations.
> 
> 
>>>>How do I know whether granting a certain permission is shadowing a
>>>>"bug" versus the right thing to do?
> 
> 
> I don't think there's any shortcut here. One has to understand what
> resources Derby accesses and does/could that new permission have any
> effect on those existing accesses.
> 
> There were/are two ways that I see that granting a permission for reason
> X could hide a bug:
> 
>   1) The permission is granted to multiple jars when only one jar
> requires it. Now that the policy file for the tests split the grants
> into per-jar sections the chance of this should be low.
> 
>   2) The permission granted is broader than is actually required for X,
> and so other code can using it without anyone realising that such a
> dependency exists. E.g. granting read on all properties hides the fact
> that the engine might be incorrectly reading user.dir when it should be
> limited to derby.* properties.
> 
> Part of my DERBY-615 work is to deliver a write-up on the existing
> security permissions needed.
> 
> Dan.
> 
> 

Re: Working with security policy

[Daniel John Debrunner <dj...@apache.org>]

David W. Van Couvering wrote:


>>> When I was doing the classloader work, I had to grant permission to
>>> the Derby codebase to be able to do classloader-related work
>>> (createClassloader, accessClassInPackage.sun.reflect, getClassloader,
>>> getProtectionDomain).

If there's a good justification for a permission then it's fine to make
Derby dependent on it. From a high level view of what you are doing I
would have concerns about Derby code needing
accessClassInPackage.sun.reflect, getClassloader and
getProtectionDomain. Esepecially the one with sun.reflect, isn't that
granting internal access to a class of a specific VM implementation?

I look at the problem from the view of someone who is running Derby on
behalf of a third-party application on their own machine. What minimal
set of permissions do they have to grant to Derby? What's the
explanation for those permissions? Can they feel comfortable running
such an application with the permissions granted?

If we said Derby has to be granted permission to read all files, read
and write all system properties, etc. then Derby would not be attractive
in those situations.

>>> How do I know whether granting a certain permission is shadowing a
>>> "bug" versus the right thing to do?

I don't think there's any shortcut here. One has to understand what
resources Derby accesses and does/could that new permission have any
effect on those existing accesses.

There were/are two ways that I see that granting a permission for reason
X could hide a bug:

  1) The permission is granted to multiple jars when only one jar
requires it. Now that the policy file for the tests split the grants
into per-jar sections the chance of this should be low.

  2) The permission granted is broader than is actually required for X,
and so other code can using it without anyone realising that such a
dependency exists. E.g. granting read on all properties hides the fact
that the engine might be incorrectly reading user.dir when it should be
limited to derby.* properties.

Part of my DERBY-615 work is to deliver a write-up on the existing
security permissions needed.

Dan.

Re: Working with security policy

["David W. Van Couvering" <Da...@Sun.COM>]

Kathey Marsden wrote:
> David W. Van Couvering wrote:
> 
> 
>>When I was doing the classloader work, I had to grant permission to
>>the Derby codebase to be able to do classloader-related work
>>(createClassloader, accessClassInPackage.sun.reflect, getClassloader,
>>getProtectionDomain).
>>
>>How do I know whether granting a certain permission is shadowing a
>>"bug" versus the right thing to do?
> 
> 
> I was a little confused by this question,  but I think in general, if
> existing tests started needing new permissions, that would be a bug.

Well, that doesn't seem completely fair.  If I am adding new, valuable 
functionality that requires new permissions, I think it's reasonable to 
add them to the list.  How would I get my classloader work in, for instance?

> 
> We don't ship a default policy file but have samples in the
> documentation.    It would be good to have security manager on and
> sample policy files  used with the framework scripts, particularly for
> network server.

Yes, I think that would be great...  Not yet itching enough to scratch 
this, though...

David

>  
> Thanks
> 
> Kathey
> 
> 

Re: Working with security policy

[Kathey Marsden <km...@sbcglobal.net>]

David W. Van Couvering wrote:

> When I was doing the classloader work, I had to grant permission to
> the Derby codebase to be able to do classloader-related work
> (createClassloader, accessClassInPackage.sun.reflect, getClassloader,
> getProtectionDomain).
>
> How do I know whether granting a certain permission is shadowing a
> "bug" versus the right thing to do?

I was a little confused by this question,  but I think in general, if
existing tests started needing new permissions, that would be a bug.

> I suspect what you want is as refined a policy as possible -- granting
> only the necessary permissions to the necessary jar file(s).
>
I agree

> Also, if I need to grant new permissions, as above, what documentation
> do I need to change.  Where is the "default policy file" that we ship
> to users (or does such a file not yet exist), as I would obviously
> need to modify this...  Is derby_tests.policy being used as a template
> for this?
>
We don't ship a default policy file but have samples in the
documentation.    It would be good to have security manager on and
sample policy files  used with the framework scripts, particularly for
network server.
 
Thanks

Kathey