db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "SecurityExpectations" by RichardHillegas
Date Fri, 05 Jan 2007 19:18:37 GMT
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. ||

Mime
View raw message