Security Expectations

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:

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:

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

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.

Open

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".

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

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:

Details of Customized Policy

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

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

A variation on this approach would be to give NetworkServerControl a new command, "print-policy", in addition to "start" and "shutdown". Note that the policy files differ for "start" vs."shutdown" and the policy files also differ based on other command line flags. A "print-policy" command would have to handle all of the variety of the "start" and "shutdown" commands. For this reason, it seems simpler to model policy-file-emitting as a qualification of the existing commands rather than as a command in its own right.

Details of Open Policy

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

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.

SecurityExpectations (last edited 2009-09-20 22:12:25 by localhost)