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 "JavaRoutineSecurity" by DanDebrunner
Date Wed, 13 Dec 2006 04:46:54 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 DanDebrunner:
http://wiki.apache.org/db-derby/JavaRoutineSecurity

New page:
= Java Routine Security =
[[TableOfContents]]
== Java routines ==
Java routines are SQL external functions and procedures implemented by the application in
Java.
Allowing creation of Java routines gives rise to some security concerns as it
provides the ability for a remote client to execute arbitary Java code on the server.
This page defines what the security holes are and the mechanisms (current or future) to close
them.
== Class categories ==
A class loaded directly or indirectly by a Java routine can come from one of five locations:

|| '''Location''' || '''Description''' ||
|| '''JRE''' || Classes provided by the JRE - Derby assumes any class in the `java.` and `javax.`
namespaces are in this category ||
|| '''CP''' || Classes accessible through standard Java classloading (CLASSPATH, parent class
loader, thread context class loader). Note that the contents of the classes available in this
group may be unknown to a remote cracker, but potentially could gain clues from stack traces
etc. ||
|| '''DBCP''' || Classes in installed jar files that ''are'' listed in `derby.database.classpath`.
Permission add a class into this set is by controlled EXECUTE permission on the procedure
to set a database property and the SQLJ procedures. Initially only the database owner has
permission to execute these SQLJ procedures. ||
|| '''SQLJAR''' || Classes in an installed jar file that ''is not'' listed in `derby.database.classpath`.
Permission to install, replace or remove a jar file is controlled by EXECUTE permission on
the SQLJ procedures. Initially only the database owner has permission to execute the SQLJ
procedures. ||
|| '''DERBY''' || Classes in `derby.jar` and `derbynet.jar`. A special case of CP since the
Derby classes will be known to be on the classpath and they are open source, which means that
a cracker could have studied them for potential security holes. ||

== Resolving Classes ==
A mapping that shows where a class referenced directly or indirectly by a routine can be loaded
from.

=== EXTERNAL NAME 'package.class.method[(signature)]' ===
The only way routines can ''currently'' be defined in Derby. The defined method in the EXTERNAL
NAME clause maps to a public static Java method in a public class. Non-standard (from SQL
Part 13 point of view) but supported by multiple databases.
Basic security risk is that there is no control or limitation over which Java methods the
routine can be defined against.

==== Entry Point class ====
The class specified in the EXTERNAL NAME clause can be resolved as:

|| '''Location''' || '''Resolve''' || '''Visibility''' || '''Security Risks''' ||
|| '''JRE''' || YES || Call any public static method provided by the JRE || ||
|| '''CP''' || YES || Call any public static method on the classpath. || ||
|| '''DBCP''' || CONTROLLED (by database owner) || Call any public static method in the installed
jar files on the database classpath. || ||
|| '''SQLJAR''' || NO |||| none, jar not visible. ||
|| '''DERBY''' || YES || Call any Derby engine or network class public static method. || ||

When a Security Manager is installed public static method can not directly access any resource
(e.g. `java.lang.System.exit`, `System.getProperty`) since Derby generates code to execute
a SQL statement that calls a routine and that generated code has no permissions granted to
it. 

==== Referenced Classes ====
The EXTERNAL NAME clause defines an entry point for the routine, if the class containing the
static method is in
an installed jar on the database class path file then that class may reference other classes
as follows:

|| '''Location''' || '''Resolve''' || '''Visibility''' || '''Security Risks''' ||
|| '''JRE''' || YES (required) || Access any class provided by the JRE ||  ||
|| '''CP''' || YES || Access any class available on the classpath. ||  ||
|| '''DBCP''' || CONTROLLED (at the database level by database owner) || Access any class
available on the database classpath. || ||
|| '''SQLJAR''' || NO |||| none, jar not visible. ||
|| '''DERBY''' || YES || Access any Derby engine or network class || ||

When a Security Manager is installed access to any resource requiring Java policy permissions
is controlled by the system owner through the policy file. Code can only access resources
if the policy file allows and the resource is accessed in a privileged block.  Granting permissions
to an installed jar file can not be done through a code source URL since Derby does not provide
a URL for an installed jar. It can be granted to the code if the installed jar is signed.

=== EXTERNAL NAME 'jarid:package.class.method[(signature)]' ===
Potential enhancement to Derby following the SQL Standard, increases security by specifying
which installed jar file
the class must come from and USAGE on jars is controlled by GRANT/REVOKE.

==== Entry Point class ====
The class specified in the EXTERNAL NAME clause can be resolved as:

|| '''Location''' || Resolve || '''Visibility''' || '''Security Risks''' ||
|| '''JRE''' || NO |||| none, only resolve to class in specified jar. ||
|| '''CP''' || NO|||| none, only resolve to class in specified jar. ||
|| '''DBCP''' || NO |||| none, only resolve to class in specified jar. ||
|| '''SQLJAR''' || CONTROLLED (requires USAGE on jar to create routine) || Call any public
static method in the specified installed jar || ||
|| '''DERBY''' || NO |||| none, only resolve to class in specified jar. ||

==== Referenced Classes ====
The accessible classes for a class within an installed jar (not on the database classpath)
is limited to the installed jar itself, its optional classpath and the JVM classes. The installed
jar's optional classpath is.

|| '''Location''' || Resolve || '''Visibility''' || '''Security Risks''' ||
|| '''JRE''' || YES (required) || Access any class provided by the JRE || ||
|| '''CP''' || NO |||| none, only resolve to class in specified jar or its classpath. ||
|| '''DBCP''' || NO |||| none, only resolve to class in specified jar or its classpath. ||
|| '''SQLJAR''' || CONTROLLED (requires USAGE on any jar listed in jar's classpath) || Access
any class in the specified installed jar or its classpath || ||
|| '''DERBY''' || NO |||| none, only resolve to class in specified jar or its classpath. 
||

When a Security Manager is installed access to any resource requiring Java policy permissions
is controlled by the system owner through the policy file. Code can only access resources
if the policy file allows and the resource is accessed in a privileged block.  Granting permissions
to an installed jar file can not be done through a code source URL since Derby does not provide
a URL for an installed jar. It can be granted to the code if the installed jar is signed.

== Security Risks ==

 * JREBUG - Security bug exists in the JRE allowing user code to access resources. Typically
the assumption for Derby to be secure is that it is operating in a secure environment which
includes JRE's virtual machine and its class libraries.
 * CPBUG - Security bug exists in the application or framework code on the classpath (CP).
Most likely a higher probability than a security bug in the JRE, typically would be caused
by some path to a privileged block that allowed malicious code to exploit permissions granted
to the application or framework code.
 * DERBYBUG - Security bug exists in Derby's engine or network code. Most likely a higher
probability than a security bug in the JRE, typically would be caused by some path to a privileged
block that allowed malicious code to exploit permissions granted to the Derby's code. Since
the Derby code is the database engine it's guaranteed to have permissions to access the database
files and thus potential exists for security holes that allow an application to access the
data bypassing database level security.

== Assumptions ==

 * The JRE is assumed to be secure with no security bugs
 * A Java Security Manager is a basic requirement for a secure client server environment
 * The policy file is valid and grants the require permissions correctly
 * Granting the ability to install jars (SQLJ procedures) means the user is trusted (? maybe
not an assumption ?)
 * Trusted users do not malicious jar in installed files. (? maybe not an assumption ?)

Mime
View raw message