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 05:03:07 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

------------------------------------------------------------------------------
  
  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.
  
+ == Permissions required to install a jar ==
+ All of these permissions must exist before a user can install (or replace) a jar.
+ 
+  * user must be able to connect to the database with read/write access level
+  * SQL EXECUTE permission to SQLJ.INSTALL_JAR has been granted to the user
+  * Either the user has permission to write a file on the server machine and Java permission
exists for derby.jar to read that location
+  * Or the user can provide a valid URL to the jar file and Java permission exists for derby.jar
to open that URL.
+ 
+ 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).
+ 
  == 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.
@@ -86, +96 @@

   * 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
+  * 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 jar in installed files. (? maybe not an assumption ?)
+  * Trusted users do not malicious code in installed jars. (? maybe not an assumption ?)
  
+ == Security risks with 10.2 ==
+ Based upon the assumptions:
+ 
+  * 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
+ 

Mime
View raw message