Differences between revisions 2 and 3
Revision 2 as of 2007-01-08 14:53:10
Size: 9555
Comment:
Revision 3 as of 2009-09-20 22:12:25
Size: 9555
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
[[TableOfContents]] <<TableOfContents>>

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:

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

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

  • 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

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:

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

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