Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 09 Nov 2007 10:32:47 +0100
From: Dyre.Tjeldvoll@Sun.COM
Subject: Re: Installing a SecurityManager by default when the server boots
In-reply-to: <x1o31wazsrjk.fsf@sun.com>
Sender: Dyre.Tjeldvoll@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x1o3wssrrcg0.fsf@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <47320BAE.60609@sun.com> <x1o31wazsrjk.fsf@sun.com>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.1 (usg-unix-v)

Dyre.Tjeldvoll@Sun.COM writes:

> Rick Hillegas <Richard.Hillegas@Sun.COM> writes:
>
>> As of release 10.3, when you boot the network server from the command
>> line, the server installs a Java SecurityManager with a default
>> policy. This change (DERBY-2196) limits the ability of hackers,
>> connecting from arbitrary machines, to use Derby to corrupt the
>> environment in which it is running. In addition, this change provides
>> a foundation on which we can add more security features
>> incrementally. As a result of this change, we have learned more about
>> how Derby behaves when run under a SecurityManager--that in turn, has
>> helped us discover more permissions which we need to add to the
>> template used as a starting point for configuring a Derby security
>> policy.
>>
>> Unfortunately, this change has proved painful to some users. See, for
>> instance, DERBY-3086 and the ongoing discussion on DERBY-3083.
>>
>> Now that we have some experience with the 10.3 release, I would like
>> to ask the community to review the wisdom of this change. Do we still
>> think that this is the correct default behavior? Or should we consider
>> turning off this feature in the upcoming 10.3 maintenance release?
>
> Personally, I have always been a fan of the "if you don't need it,
> you should not have to pay for it" philosophy. Where "pay" could mean
> anything from a performance hit to extra hassles when getting started.

An example: If I start the Swing-based JUnit test runner with a suite
as argument, it runs fine. But if I try to browse for another suite or test
from the same runner I get

Exception in thread "AWT-EventQueue-0" java.security.AccessControlException: access denied (java.util.PropertyPermission java.class.path read)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
        at java.lang.System.getProperty(System.java:652)
        at junit.runner.ClassPathTestCollector.collectTests(ClassPathTestCollector.java:25)
        at junit.swingui.TestSelector.createTestList(TestSelector.java:257)
        at junit.swingui.TestSelector.<init>(TestSelector.java:125)
        at junit.swingui.TestRunner.browseTestClasses(TestRunner.java:532)
        at junit.swingui.TestRunner$10.actionPerformed(TestRunner.java:348)


Now, what nasty hacker attack is prevented by not letting
JUnit read the classpath :)

-- 
dt