Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Fri, 05 Jan 2007 19:18:37 -0000
Message-ID: <20070105191837.6994.69105@eos.apache.osuosl.org>
Subject: [Db-derby Wiki] Update of "SecurityExpectations" by RichardHillegas

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by RichardHillegas:
http://wiki.apache.org/db-derby/SecurityExpectations

New page:
= Security Expectations =
[[TableOfContents]]
== Overview ==

Currently, Derby is very trusting. This is fine for single-user, shrink-wrapped applications which don't care about protecting themselves from accidents or hackers. It's probably also fine for multi-user applications provided that a wrapping application hides Derby's JDBC and SQL apis from prying eyes.  However, this kind of trust seems misplaced for applications which expose Derby's apis to mistakes and malice. In particular, we need to consider Derby's exposure when running under our network server. In this scenario, by obtaining a JDBC connection and issuing ad hoc SQL, groggy or grumpy users could trash data, hog resources, kill servers, etc..

Consider the following sample problems:

 * Today, anyone who can connect to Derby can also shutdown the whole engine by inserting some properties into the JDBC connection url.
 * In addition, a connected user can shutdown the whole VM by first wrapping System.exit() in a Derby procedure and then calling that procedure.

Users can control the second problem by running the network server under a !SecurityManager, as described in the Admin Guide. We could use the !SecurityManager to control the first problem too--although we don't today. !SecurityManager-based solutions are attractive for the following reasons:

 * '''Standard''' - The Java Security Architecture has been standard since jdk 1.4.
 * '''Germane''' - These are the kinds of system resource problems which Java Security is designed to tackle.
 * '''Mature''' - We have already invested a fair amount of effort in making Derby run under a !SecurityManager.

However, !SecurityManager-based solutions suffer from the following drawbacks:

 * '''Learning Curve''' - It takes a couple days to digest the relevant documentation on Java Security. This is a steep learning curve for users who are not familiar with this technology.
 * '''Tricky API''' - The key api for customers, the policy file, can be tricky to construct. Mistakes in policy files or on the Java startup command can surface as confusing diagnostics or even silent failures.

We feel that the advantages of Java Security outweigh the disadvantages.

== Security Expectations ==

One size does not fit all. A multi-user app running under our network server could want any of the following security policies:

|| '''Policy''' || '''Description''' ||
|| '''Basic''' || This would be a generic, default policy. This policy would try to be both secure-by-default and usable out-of-the-box. ||
|| '''Customized''' || This would be a user-modified, application-specific policy which tightens or loosens the Basic rules. ||
|| '''Exposed''' || This is today's anything-goes policy. ||

We would like to make it easy to configure any of these policies. Policy details follow.

== Details of Basic Policy ==

We propose that by default, the network server should come up under a !SecurityManager. That is, when the VM comes up with the network server as its main entry point, then the network server will install a !SecurityManager if one wasn't specified on the command line. So, for instance, the network server will install a !SecurityManager to enforce the Basic startup policy if you bring up the VM with the following command:

`    java org.apache.derby.drda.NetworkServerControl start -p 1368`

The Basic startup policy is the one documented in the Admin Guide section titled "Running the Network Server under the !SecurityManager". It grants the following permissions to all of the jar files in the derby lib directory: socket reading permission plus all of the permissions needed to run an embedded Derby engine--those permissions are documented in the Developer's Guide section titled "Running Derby under a security manager".

 * '''Sockets''' - The ability to accept connections on the server socket.
 * '''Classloaders''' - The ability to create class loaders.
 * '''Databases''' - The ability to read/write/delete in all databases under Derby's system home.
 * '''Properties''' - The ability to read all properties in the "derby" namespace plus the "user.dir" property.
 * '''Other''' - As we tighten Derby security, we may add more default permissions. For instance, if we control shutdown privilege via Java Security, then we will need to grant shutdown privilege  to some Principal.

The code which creates this Basic startup policy file will have to figure out the following:

 * '''Jar Location''' - The directory holding the derby jars
 * '''System Home''' - The location of Derby's system home.
 * '''Host''' - The host name for the socket.
 * '''Other''' - Again, if we control shutdown privilege via Java Security, then the server startup code will need to figure out which user is entitled to shutdown the engine.

Similarly, the server shutdown command should install a !SecurityManager. That is, when the VM comes up with network server shutdown as its main entry point, then shutdown logic will install a !SecurityManager if one wasn't specified on the command line:

`    java org.apache.derby.drda.NetworkServerControl shutdown -p 1368`

The Basic shutdown policy is also documented in the Admin Guide section titled "Running the Network Server under the security manager". It grants socket permissions to all jar files in the derby lib directory:

 * '''Sockets''' - The ability to accept, connect, and resolve connections on the server socket.

== Details of Customized Policy ==

The Basic policy may not satisfy some customers. For instance:

 * '''Extend''' - The customer may be running the network server in the same VM with some web server or other applications which need their own sets of permissions. In this case, the customer will need to augment the Basic policy with more permissions.
 * '''Restrict''' - The customer may want to limit the server to touching only a few databases/directories.

To help the customer customize the Basic policy, we can provide a new flag, "-b", on the start and shutdown commands. When this flag is set, !NetworkServerControl won't actually start or shutdown the server. Instead, !NetworkServerControl will simply print its Basic policy to standard out. So for instance, the following command will print out the Basic startup policy:

`    java org.apache.derby.drda.NetworkServerControl start -b -p 1368`

The following command will print out the Basic shutdown policy:

`    java org.apache.derby.drda.NetworkServerControl shutdown -b -p 1368`

== Details of Exposed Policy ==

Other customers may not want to run the network server under a !SecurityManager at all. For instance:

 * '''Ignore''' - The customer may want to integrate the network server into an existing application which does not run with a !SecurityManager. The customer may feel confident that she does not need to secure the server and she may not want to have to figure out all of the permissions which she would need to secure her legacy applications.

To support these customers, we can add another flag, "-i", on the start and shutdown commands. When this flag is set, !NetworkServerControl will not install its own !SecurityManager. So for instance, the following command will bring up the network server without a !SecurityManager, as happens today:

`    java org.apache.derby.drda.NetworkServerControl start -i -p 1368`

== Upgrade Experience ==

The first release which implemented these proposals would affect customers as follows:

|| '''Scenario''' || '''Old behavior''' || '''New behavior''' || '''Customer needs to make these changes...''' ||
|| '''Insecure Standalone Server''' || In this scenario, !NetworkServerControl is the main entry point for the VM and the VM starts up without a !SecurityManager.  || The server should come up as before. However, under the hood, !NetworkServerControl will install a !SecurityManager. The customer would now experience any bugs which plague Derby when running under a !SecurityManager. || Probably the customer will not need to do anything. However, the customer may need to bring the server up with the "-i" flag if the application is adversely affected by bugs which plague Derby when running under a !SecurityManager. ||
|| '''Secure Standalone Server''' || In this scenario, !NetworkServerControl is also the main entry point for the VM. However, in this scenario the customer is already bringing the server up under a !SecurityManager. || Nothing changes for the customer. Because a !SecurityManager is already running, !NetworkServerControl will not try to bring one up. The existing policy file, which used to work, should continue to work. || No changes necessary. ||
|| '''Embedded Server''' || In this scenario, the network server runs inside the same VM with other applications, but is not the main entry point. || Nothing changes for the customer. Because !NetworkServerControl is not the main entry point, it will not try to bring up a !SecurityManager. || No changes necessary. ||