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 19:23:47 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

------------------------------------------------------------------------------
  ==== Entry Point class ====
  The class specified in the EXTERNAL NAME clause can be resolved as:
  
- || '''Location''' || '''Resolve''' || '''Visibility''' || '''Security Risks''' ||
+ || '''Location''' || '''Resolve''' || '''Visibility''' ||
- || '''JRE''' || YES || Call any public static method provided by the JRE || ||
+ || '''JRE''' || YES || Call any public static method in a public class provided by the JRE
||
- || '''CP''' || YES || Call any public static method on the classpath. || ||
+ || '''CP''' || YES || Call any public static method in a public class on the classpath.
||
- || '''DBCP''' || CONTROLLED (by database owner) || Call any public static method in the
installed jar files on the database classpath. || ||
+ || '''DBCP''' || CONTROLLED (by database owner) || Call any public static method in a public
class in the installed jar files on the database classpath. ||
- || '''SQLJAR''' || NO |||| none, jar not visible. ||
+ || '''SQLJAR''' || NO || none, jar not visible. ||
- || '''DERBY''' || YES || Call any Derby engine or network class public static method. ||
||
+ || '''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. 
  
@@ -40, +40 @@

  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''' ||
+ || '''Location''' || '''Resolve''' || '''Visibility''' ||
- || '''JRE''' || YES (required) || Access any class provided by the JRE ||  ||
+ || '''JRE''' || YES (required) || Access any class provided by the JRE ||
- || '''CP''' || YES || Access any class available on the classpath. ||  ||
+ || '''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. || ||
+ || '''DBCP''' || CONTROLLED (at the database level by database owner) || Access any class
available on the database classpath. ||
- || '''SQLJAR''' || NO |||| none, jar not visible. ||
+ || '''SQLJAR''' || NO || none, jar not visible. ||
- || '''DERBY''' || YES || Access any Derby engine or network class || ||
+ || '''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)]' ===
+ === EXTERNAL NAME 'jarid:package.class.method[(signature)]' (FUTURE) ===
  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''' ||
+ || '''Location''' || Resolve || '''Visibility''' ||
- || '''JRE''' || NO |||| none, only resolve to class in specified jar. ||
+ || '''JRE''' || NO || none, only resolve to class in specified jar. ||
- || '''CP''' || 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. ||
+ || '''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 || ||
+ || '''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. ||
+ || '''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''' ||
+ || '''Location''' || Resolve || '''Visibility''' ||
- || '''JRE''' || YES (required) || Access any class provided by the JRE || ||
+ || '''JRE''' || YES (required) || Access any class provided by the JRE ||
- || '''CP''' || NO |||| none, only resolve to class in specified jar or its classpath. ||
+ || '''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.
||
+ || '''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 || ||
+ || '''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.
 ||
+ || '''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.
  
@@ -85, +85 @@

  
  Note that this is not possible when a security manager is installed in 10.2 or earlier releases
dues to DERBY-537 (fixed in trunk).
  
+ == Setting derby.database.classpath ==
+ 
+ Permission to set database classpath is limited by the permission to execute SYSCS_UTIL.SET_DATABASE_PROPERTY.
+ No restriction is placed on which jar files can be added to the database classpath.
+ 
+ In terms of the functionality described by SQL Standard Part 13 setting the database classpath
is equivalent to:
+  * Implicitly granting USAGE to PUBLIC on any jar file listed in derby.database.classpath
+  * Implicitly setting any installed jar's classpath (See SQLJ.ALTER_JAVA_PATH) to the value
of derby.database.classpath.
+ 
- == Security Risks ==
+ == Potential 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.
+  * JARBUG - Security bug exists in the application code in an installed jar (DBCP, SQLJAR).
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's installed jar.
  
  == 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
+  * SQL Authorization mode is enabled
+  * Users are authenticated
-  * If a user has the ability to access the server file system then can 
-  * Granting the ability to install jars (SQLJ procedures) means the user is trusted (? maybe
not an assumption ?)
-  * Trusted users do not malicious code in installed jars. (? maybe not an assumption ?)
  
- == Security risks with 10.2 ==
+ == Security with 10.2, 10.1 and 10.0 ==
  Based upon the assumptions:
+ === Limitations ===
  
+  * No jar files can be installed due to [http://issues.apache.org/jira/browse/DERBY-537
DERBY-537]
+  * No database classpath can be set due to [http://issues.apache.org/jira/browse/DERBY-2040
DERBY-2040]
-  * Any user can create a Java routine against a public static method in JRE, CP or DERBY
-  * No jar files can be installed due to DERBY-537
-  * No database classpath can be set due to DERBY-2040
  
+ === Risks ===
+ 
+  * Any user can create a Java routine directly against a public static method in JRE, CP
or DERBY and thus can exploit '''potential''' security risks described by JREBUG, CPBUG or
DERBYBUG.
+ 
+ == Security with 10.3 onwards ==
+ Based upon the assumptions and assuming [http://issues.apache.org/jira/browse/DERBY-537
DERBY-537 (already fixed)] and [http://issues.apache.org/jira/browse/DERBY-2040 DERBY-2040]
will be fixed.
+ === Limitations ===
+ None.
+ === Risks ===
+ 
+  * Any user can create a Java routine directly against a public static method in JRE, CP
or DERBY and thus can exploit '''potential''' security risks described by JREBUG, CPBUG or
DERBYBUG.
+  * Any user can create a Java routine against a public static method in DBCP and thus can
exploit any '''potential''' security risks within the jar.
+  * Installed jars can contain (malicious) code that can exploit '''potential''' security
risks described by JREBUG, CPBUG or DERBYBUG.
+ === Improving Java Routine Security in 10.3 onwards ===
+ To reduce the '''potential''' security risks these steps could be taken:
+ || '''What''' || '''Jira''' || '''Description''' ||
+ |||||| These reduce security vulnerabilities and allow behaviour to match 10.2 ||
+ || Implement GRANT USAGE on jar files || || Follow SQL Standard Part 13 ||
+ || Restrict jars added to derby.database.classpath || || Require that an installed jar must
have USAGE granted to PUBLIC before it can be added to the derby.database.classpath. (Simple
alternative: installed jar is ignored in classpath unless it has USAGE granted to PUBLIC).
 Explicit change in behaviour from 10.2 to improve security ||
+ || Only expose Derby's api || [http://issues.apache.org/jira/browse/DERBY-467 DERBY-467]
|| Disallow any routine or classes loaded from an installed jar to reference any class in
the namespace `org.apache.derby.` unless it is part of Derby's public api. Reduces the possibility
for routines to exploit security bugs in Derby. ||
+ || Define pseudo jar `SYS.CLASSPATH` || || Jar name that represents the classpath (CP),
requires USAGE to be granted like any other jar, by default USAGE is only granted to the database
owner. This provides controlled access to code on the classpath. If `SYS.CLASSPATH` is granted
to PUBLIC then it is implicitly included in derby.database.classpath as in 10.2. Explicit
change in behaviour from 10.2 to improve security ||
+ || Define pseudo jar `SYS.JRE` || || Jar name that represents the JRE classes. Creating
a routine that directly uses a JRE public static method would require USAGE to be granted
on this jar. Note that since JRE usage must be supported when resolving from an installed
jar `SYS.JRE` behaves differently to other jars. If `SYS.JRE` is granted to PUBLIC then it
is implicitly included in derby.database.classpath as in 10.2. This does not close the vulnerability
to JREBUGs through malicious code in installed jars, because Java code needs access to the
standard Java libraries. Explicit change in behaviour from 10.2 to improve security ||
+ |||||| These provide additional functionality for Java routines ||
+ || Support jarid in EXTERNAL NAME || || Allows users to create their own routines without
exposing their code to all users. Require to implement class loading that is resticted to
the given jar even for referenced classes. Without this then the only useful USAGE grant on
an installed jar is one to PUBLIC. ||
+ || Implement SQLJ.ALTER_JAVA_PATH || || Allows installed jars to reference multiple jars
routine entry point is defined with a jar id ||
+ 
+ 
+ == Example Attacks ==
+ === Accessing database files directly ===
+ Accessing the database files directly thus bypassing database level security in order to
read or modify a table one does not have access to.
+  * Direct calls to JRE methods from a routine will fail to open any files because the calling
stack contains the generated code and that class has no permissions.
+  * Not granting Java permissions to the installed jars to read or modify the database files
will stop any access even if the code is in a privileged block.
+ 
+ === Denial of service attacks ===
+ Denial of service attacks such as shutting down the JVM
+  * Direct call to `java.lang.System.exit()` will fail because the calling stack contains
the generated code and that class has no permissions.
+  * Executing slow Java methods on the server through Java routines, e.g. java.lang.System.gc()`
- not an issue due to Java routines, client could send endless valid SQL queries to slow a
system down.
+ 

Mime
View raw message