Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <434946C8.6000706@debrunners.com>
Date: Sun, 09 Oct 2005 09:35:20 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev <derby-dev@db.apache.org>
Subject: Proposal for change in test harness & security manager
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.