You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@debrunners.com> on 2005/10/09 18:35:20 UTC
Proposal for change in test harness & security manager
Currently any test that runs the network server as a separate java
executable uses the security manager and a policy file (nwsvr.policy)
for the network server's JVM. This is a good step but I've been looking
to improve the situation to run most tests under the security manager
(by default).
Current Behaviour
-----------------
The harness determins a code base from the class path and sets this as
the property csinfo.codebase for the policy file. This code base will
correspond to either the classes directory or the directory containing
derby jar files. The policy file (nwsvr.policy) then has a set of
permissions that are granted to the code base, which is the entire derby
code.
Issue with the current behaviour
--------------------------------
Granting permissions to a single code base that includes all the derby
code can lead to hidden bugs, especially due to the fact the test
harness does not need to be secure and is not designed that way, whereas
the other derby components need to be secure. For example, the test
harness needs to read and modify system properties so that permission is
granted, now the engine should not be needing that permission but due to
the single code base in the policy file, it has that permission and now
silently could start to depend on it.
Proposed change
---------------
I have a more specific properties file (derby_tests.policy) that has a
section for each derby jar file with code, and grants only the required
(and reasonable) permissions for each jar. E.g. derby.jar is not granted
any socket related permissions and derbynet.jar is not granted any
access to the database files. With this file incorrect permissions that
need to be granted are obvious and bugs can be entered against them.
In addition a section in the policy file will exist for the classes
directory with a superset of the permissions. This is for when the tests
are run directly out of the classes directory.
There is a chance that the tests will pass under the classes and fail
with the jars with a contribution or change. The risk is small (and most
likely would point to a bug). Comments can be added in the policy file
indicating if changes are made to the classes section that similar
changes might be needed to the jar sections and tests should also be run
using the jars.
Justification
-------------
I strongly believe that the single code base approach today is not
sufficent for Derby's security testing, due to the potential for hidden
bugs. In switching to this new style I think I've found three bugs so
far against Derby related to permissions, including one potentially
serious one where a create index fails due to no access to a temp file.
I need to look at that one more. I think the number of bugs (so far)
shows the change is a good one.
Status
------
[I'll add this to the wiki in a while]
The first checkin would switch to the new policy file and hence just
continue to run the network server under the security manager.
Subsequent checkins would enable running tests under the security
manager including embedded tests and the client side tests. There will
be more e-mail on that before it occurs.
I'm also modifying an old Cloudscape internal document that discussed
and listed the permissions to bring it up to date and add it to the
Derby site.
I think I'll be ready for the first checkin in a few days.
BTW - the code that currently does handle the security manager and
policy file in the harness is well written, it expanded to the standard
tests very easily.
Comments etc?
Dan.
Re: Proposal for change in test harness & security manager
Posted by Francois Orsini <fr...@gmail.com>.
On 10/10/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
> Daniel John Debrunner wrote:
>
> With my changes embedded tests that run today under CDC will be run
> under the security manager.
>
> Dan.
>
>
That is what I was concerned about ;) - Thanks Dan
Re: Proposal for change in test harness & security manager
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Daniel John Debrunner wrote:
> Francois Orsini wrote:
>
>>- Have we tested running Derby with the nwsvr.policy file in a CDC
>>environment? It should work but am just wondering - CLDC, however does
>>not support security policies (from what I remember) since it relies on
>>the Sandbox model.
Actually to be clear, the network server doesn't run under CDC so
currently it doesn't make sense to run with nwsvr.policy & CDC.
With my changes embedded tests that run today under CDC will be run
under the security manager.
Dan.
Re: Proposal for change in test harness & security manager
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Francois Orsini wrote:
> Sounds great Dan. Just have a few questions.
>
> - So you're basically thinking of superceding the current nwsvr.policy
> file witha new one that has jars specific security restrictions, right?
and then moving on to running all tests under a security manager.
> In any case, it would be good to update the admin manual and make
> mention of the new security policies as example.
Yep, more documentation is needed here. The embedded has a section of
which permissions are required and why, whereas the network server only
has examples.
> - Have we tested running Derby with the nwsvr.policy file in a CDC
> environment? It should work but am just wondering - CLDC, however does
> not support security policies (from what I remember) since it relies on
> the Sandbox model.
Good point, I will ensure that this (CDC) is tested before I enable
embedded tests under the security manager.
Dan.
Re: Proposal for change in test harness & security manager
Posted by Francois Orsini <fr...@gmail.com>.
Sounds great Dan. Just have a few questions.
- So you're basically thinking of superceding the current nwsvr.policy file
witha new one that has jars specific security restrictions, right? In any
case, it would be good to update the admin manual and make mention of the
new security policies as example.
- Have we tested running Derby with the nwsvr.policy file in a CDC
environment? It should work but am just wondering - CLDC, however does not
support security policies (from what I remember) since it relies on the
Sandbox model.
--francois
Re: Proposal for change in test harness & security manager
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Actually, I don't know whether there exists concrete necessary of different security policy for same jar file in the test.
Then, I think it is sufficient that we know there is nothing to stop walkround when it was needed .
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Daniel John Debrunner" <dj...@debrunners.com>
To: "Derby Development" <de...@db.apache.org>
Sent: Monday, October 10, 2005 7:10 AM
Subject: Re: Proposal for change in test harness & security manager
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> Just to confirm my understanding ....
>>
>> I read your proposal as defining security policies for each jar files.
>
> Correct.
>
>> Does the proposal assume that the same jar file is always executed in
>> same security environments in the test ?
>
> My goal is to ensure that running derbyall tests all Derby's
> functionality works with a security manager and a correctly, minimally
> configured policy file. By minimally I mean just the fewset set of
> permissions required, hopefully in-line with the documentation. E.g. a
> policy file that allowed all permissions would work but would not be a
> good test of Derby.
>
> Other tests could be added with different policy files, or run existing
> tests with a different policy file, like some tests are run with
> encryption as well as without encryption. Some enhancments would be
> needed to the test harness for this. I'm not scratching that itch,
> though I believe nothing I doing would stop such development.
>
> Thanks,
> Dan.
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 2005/10/09
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 2005/10/09
Re: Proposal for change in test harness & security manager
Posted by Daniel John Debrunner <dj...@debrunners.com>.
TomohitoNakayama wrote:
> Hello.
>
> Just to confirm my understanding ....
>
> I read your proposal as defining security policies for each jar files.
Correct.
> Does the proposal assume that the same jar file is always executed in
> same security environments in the test ?
My goal is to ensure that running derbyall tests all Derby's
functionality works with a security manager and a correctly, minimally
configured policy file. By minimally I mean just the fewset set of
permissions required, hopefully in-line with the documentation. E.g. a
policy file that allowed all permissions would work but would not be a
good test of Derby.
Other tests could be added with different policy files, or run existing
tests with a different policy file, like some tests are run with
encryption as well as without encryption. Some enhancments would be
needed to the test harness for this. I'm not scratching that itch,
though I believe nothing I doing would stop such development.
Thanks,
Dan.
Re: Proposal for change in test harness & security manager
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Just to confirm my understanding ....
I read your proposal as defining security policies for each jar files.
Does the proposal assume that the same jar file is always executed in same security environments in the test ?
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Daniel John Debrunner" <dj...@debrunners.com>
To: "derby-dev" <de...@db.apache.org>
Sent: Monday, October 10, 2005 1:35 AM
Subject: Proposal for change in test harness & security manager
> Currently any test that runs the network server as a separate java
> executable uses the security manager and a policy file (nwsvr.policy)
> for the network server's JVM. This is a good step but I've been looking
> to improve the situation to run most tests under the security manager
> (by default).
>
> Current Behaviour
> -----------------
>
> The harness determins a code base from the class path and sets this as
> the property csinfo.codebase for the policy file. This code base will
> correspond to either the classes directory or the directory containing
> derby jar files. The policy file (nwsvr.policy) then has a set of
> permissions that are granted to the code base, which is the entire derby
> code.
>
> Issue with the current behaviour
> --------------------------------
>
> Granting permissions to a single code base that includes all the derby
> code can lead to hidden bugs, especially due to the fact the test
> harness does not need to be secure and is not designed that way, whereas
> the other derby components need to be secure. For example, the test
> harness needs to read and modify system properties so that permission is
> granted, now the engine should not be needing that permission but due to
> the single code base in the policy file, it has that permission and now
> silently could start to depend on it.
>
> Proposed change
> ---------------
>
> I have a more specific properties file (derby_tests.policy) that has a
> section for each derby jar file with code, and grants only the required
> (and reasonable) permissions for each jar. E.g. derby.jar is not granted
> any socket related permissions and derbynet.jar is not granted any
> access to the database files. With this file incorrect permissions that
> need to be granted are obvious and bugs can be entered against them.
>
> In addition a section in the policy file will exist for the classes
> directory with a superset of the permissions. This is for when the tests
> are run directly out of the classes directory.
>
> There is a chance that the tests will pass under the classes and fail
> with the jars with a contribution or change. The risk is small (and most
> likely would point to a bug). Comments can be added in the policy file
> indicating if changes are made to the classes section that similar
> changes might be needed to the jar sections and tests should also be run
> using the jars.
>
>
> Justification
> -------------
>
> I strongly believe that the single code base approach today is not
> sufficent for Derby's security testing, due to the potential for hidden
> bugs. In switching to this new style I think I've found three bugs so
> far against Derby related to permissions, including one potentially
> serious one where a create index fails due to no access to a temp file.
> I need to look at that one more. I think the number of bugs (so far)
> shows the change is a good one.
>
>
> Status
> ------
>
> [I'll add this to the wiki in a while]
>
> The first checkin would switch to the new policy file and hence just
> continue to run the network server under the security manager.
> Subsequent checkins would enable running tests under the security
> manager including embedded tests and the client side tests. There will
> be more e-mail on that before it occurs.
>
> I'm also modifying an old Cloudscape internal document that discussed
> and listed the permissions to bring it up to date and add it to the
> Derby site.
>
> I think I'll be ready for the first checkin in a few days.
>
> BTW - the code that currently does handle the security manager and
> policy file in the harness is well written, it expanded to the standard
> tests very easily.
>
> Comments etc?
> Dan.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: 2005/10/07
Re: Proposal for change in test harness & security manager
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Kathey Marsden wrote:
> Daniel John Debrunner wrote:
>
>
>>Currently any test that runs the network server as a separate java
>>executable uses the security manager and a policy file (nwsvr.policy)
>>for the network server's JVM. This is a good step but I've been looking
>>to improve the situation to run most tests under the security manager
>>(by default).
>>
>>Current Behaviour
>>-----------------
>>
>>The harness determins a code base from the class path and sets this as
>>the property csinfo.codebase for the policy file. This code base will
>>correspond to either the classes directory or the directory containing
>>derby jar files. The policy file (nwsvr.policy) then has a set of
>>permissions that are granted to the code base, which is the entire derby
>>code.
>>
>>Issue with the current behaviour
>>--------------------------------
>>
>>Granting permissions to a single code base that includes all the derby
>>code can lead to hidden bugs, especially due to the fact the test
>>harness does not need to be secure and is not designed that way, whereas
>>the other derby components need to be secure. For example, the test
>>harness needs to read and modify system properties so that permission is
>>granted, now the engine should not be needing that permission but due to
>>the single code base in the policy file, it has that permission and now
>>silently could start to depend on it.
>>
>>
>>
>
>
> I can see that this is an issue for the embedded policy file. Since
> network server only had to deal with the server side access, we did
> not have to grant the permissions needed by the harness to the codebase
> in the nwsvr.policy file. I do have some other concerns about the
> permissions in the nwsvr.policy file and I am wondering if they will be
> addressed by your changed.
>
> 1) There are a bunch of permissions that hare needed only by specific
> tests, for instance quite a few for sysinfo.
> permission java.io.FilePermission "${csinfo.codebase}/derby.jar",
> "read"; etc. Will these be in the derby_tests.policy?
I would only check in a policy file (first step) that ensured the tests
running today under the security manager continued to run. Thus if a
permission is required it will be in the policy file. Now that specific
one you mention is actually a bug (I believe). Thus it will be in the
policy file but I would enter a Jira entry indicating that the code
needs to be modified not to require that permission. The permission in
the policy file would have a comment indicating the bug number.
> 2) For a sane build we seemed to need, permission
> java.lang.RuntimePermission "accessDeclaredMembers"; which would be
> good to not have available to an insane build. Will this still be required?
As above, if required it will have to be there, but it may be a bug that
that is required. At the moment I'm only testing insane but will move
onto sane once I have sane working (and before committing). I'd seen
this one as a potential issue thanks to your comments in nwsvr.policy. :-)
>
> 3) Will both network server and embedded tests use the same
> derby_tests.policy file? Are there any issues with the extra
> permissions needed by one or the other?
Yes single policy file, I don't see any case where extra permissions are
needed, remember permissions will be granted to the individual jars,
thus I don't think derby.jar needs any more permissions to run under the
network server. Can you think of any issues?
Thanks,
Dan.
Re: Proposal for change in test harness & security manager
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>Currently any test that runs the network server as a separate java
>executable uses the security manager and a policy file (nwsvr.policy)
>for the network server's JVM. This is a good step but I've been looking
>to improve the situation to run most tests under the security manager
>(by default).
>
>Current Behaviour
>-----------------
>
>The harness determins a code base from the class path and sets this as
>the property csinfo.codebase for the policy file. This code base will
>correspond to either the classes directory or the directory containing
>derby jar files. The policy file (nwsvr.policy) then has a set of
>permissions that are granted to the code base, which is the entire derby
>code.
>
>Issue with the current behaviour
>--------------------------------
>
>Granting permissions to a single code base that includes all the derby
>code can lead to hidden bugs, especially due to the fact the test
>harness does not need to be secure and is not designed that way, whereas
>the other derby components need to be secure. For example, the test
>harness needs to read and modify system properties so that permission is
>granted, now the engine should not be needing that permission but due to
>the single code base in the policy file, it has that permission and now
>silently could start to depend on it.
>
>
>
I can see that this is an issue for the embedded policy file. Since
network server only had to deal with the server side access, we did
not have to grant the permissions needed by the harness to the codebase
in the nwsvr.policy file. I do have some other concerns about the
permissions in the nwsvr.policy file and I am wondering if they will be
addressed by your changed.
1) There are a bunch of permissions that hare needed only by specific
tests, for instance quite a few for sysinfo.
permission java.io.FilePermission "${csinfo.codebase}/derby.jar",
"read"; etc. Will these be in the derby_tests.policy?
2) For a sane build we seemed to need, permission
java.lang.RuntimePermission "accessDeclaredMembers"; which would be
good to not have available to an insane build. Will this still be required?
3) Will both network server and embedded tests use the same
derby_tests.policy file? Are there any issues with the extra
permissions needed by one or the other?
Thanks
Kathey