9 Security For Oracle Database Java Applications

9.2.2.1 Fine-Grain Definition for Each Permission

To set individual Permissions within the policy table, you must provide the following information:

You can either grant Java 2 Permissions or create your own. The Java 2 Permissions are listed in Table 9-1. If you would like to create your own Permissions, see "Creating Permissions".

You can grant permissions using either SQL or Java, as shown below. However, each returns a row key identifier that identifies the row within the permission table. In the Java version of DBMS_JAVA, each method returns the row key identifier, either as a returned parameter or as an OUT variable in the parameter list. In the PL/SQL DBMS_JAVA package, the row key is returned only in the procedure that defines the key OUT parameter. This key is used to enable and disable specific Permissions. See "Enabling or Disabling Permissions" for more information.

If, after executing the grant, a row already exists for the exact Permission, no update occurs, but the key for that row is returned. If the row was disabled, executing the grant enables the existing row.

Granting Permissions using the DBMS_JAVA package:

procedure grant_permission( grantee varchar2, permission_type varchar2,      permission_name varchar2,       permission_action varchar2 )

procedure grant_permission( grantee varchar2, permission_type varchar2,    permission_name varchar2,       permission_action varchar2, key OUT number)

Granting Permissions using Java:

long oracle.aurora.rdbms.security.PolicyTableManager.grant(          java.lang.String grantee,       java.lang.String permission_type,       java.lang.String permission_name,       java.lang.String permission_action);


void oracle.aurora.rdbms.security.PolicyTableManager.grant(        java.lang.String grantee,       java.lang.String permission_type,       java.lang.String permission_name,       java.lang.String permission_action,     long[] key);

Limiting Permissions using the DBMS_JAVA package:

procedure restrict_permission( grantee varchar2, permission_type varchar2,   permission_name varchar2,       permission_action varchar2)

procedure restrict_permission( grantee varchar2, permission_type varchar2,         permission_name varchar2,       permission_action varchar2, key OUT number)

Limiting Permissions using Java:

long oracle.aurora.rdbms.security.PolicyTableManager.restrict(       java.lang.String grantee,       java.lang.String permission_type,       java.lang.String permission_name,       java.lang.String permission_action);

void oracle.aurora.rdbms.security.PolicyTableManager.restrict(       java.lang.String grantee,       java.lang.String permission_type,       java.lang.String permission_name,       java.lang.String permission_action,     long[] key);

connect larry/larry


REM Grant DAVE permission to read and write the Test1 file.

call dbms_java.grant_permission('DAVE',          'java.io.FilePermission', '/test/Test1',        'read,write');


REM commit the changes to the PolicyTable

commit;

The explicit rule is as follows:

If the limitation Permission implies the request, then for a grant to be effective, the limitation Permission must also imply the grant.

The following is the code that implements this example:

1. Grant everyone (PUBLIC) read and write permission to all files in /tmp.

2. Limit everyone (PUBLIC) from reading or writing only the password file in /tmp.

3. Grant only Larry (owner) explicit permission to read and write the password file.

connect larry/larry


REM Grant permission to all users (PUBLIC) to be able to read and write REM all files in /tmp.

call dbms_java.grant_permission('PUBLIC',        'java.io.FilePermission',       '/tmp/*',       'read,write');


REM Limit permission to all users (PUBLIC) from reading or writing the 

REM password file in /tmp. 

call dbms_java.restrict_permission('PUBLIC',     'java.io.FilePermission',       '/tmp/password',        'read,write');


REM By providing a more specific rule that overrides the limitation,

REM Larry can read and write /tmp/password.

call dbms_java.grant_permission('LARRY',         'java.io.FilePermission',       '/tmp/password',        'read,write');

commit;

9.2.2.2 Acquiring Administrative Permission to Update Policy Table

All Permissions are rows within the policy table. As it is a table within the database and thus a resource, permission is needed to modify it. Specifically, the PolicyTablePermission object is required to modify the table. After the first initialization for OracleJVM, only a single role—JAVA_ADMIN—is granted the PolicyTablePermission to modify the policy table. The JAVA_ADMIN role is immediately assigned to DBA; thus, if you are assigned to the DBA group, you will automatically take on all JAVA_ADMIN Permissions.

For you to be able to add Permissions as rows to this table, JAVA_ADMIN must grant your schema update rights for the PolicyTablePermission. This Permission defines that your schema can add rows to the table. Each PolicyTablePermission is for a specific Permission type. For example, for you to add a Permission that controls access to a file, you must have a PolicyTablePermission that allows you to grant or limit a Permission on a FilePermission. Once this occurs, you have administrative Permission for FilePermission.

The administrator could grant and limit the PolicyTablePermissions in the same manner as other Permissions, but the syntax is complicated. For ease of use, use one of the following methods within the DBMS_JAVA package to grant administrative Permissions.

Granting policy table administrative Permissions using DBMS_JAVA:

procedure grant_policy_permission( grantee varchar2, permission_schema varchar2, 

 permission_type varchar2,       permission_name varchar2)

procedure grant_policy_permission( grantee varchar2, permission_schema varchar2, 

 permission_type varchar2,       permission_name varchar2,       key OUT number)

Granting policy table administrative permission using Java:

long oracle.aurora.rdbms.security.PolicyTableManager.grantPolicyPermission(  java.lang.String grantee,       java.lang.String permission_type,       java.lang.String permission_name);

void oracle.aurora.rdbms.security.PolicyTableManager.grantPolicyPermission(   java.lang.String grantee,       java.lang.String permission_type,       java.lang.String permission_name,       long[] key);

REM Connect as SYS, which is assigned JAVA_ADMIN role, to give Larry permission  REM to modify the PolicyTable

connect SYS/SYS as SYSDBA


REM SYS grants Larry the right to administer permissions for

REM FilePermission

call dbms_java.grant_policy_permission('LARRY', 'SYS',   'java.io.FilePermission', '*');

9.2.2.3 Creating Permissions

Create your own Permission type by performing the following steps:

1. Create and load the user Permission.

2. Grant administrative and action Permissions to specified users.

3. Implement security checks using the Permission.

package test.larry;

import java.security.Permission;

import java.security.BasicPermission;


public class MyPermission extends BasicPermission {


  public MyPermission(String name) {

    super(name);

  }


  public boolean implies(Permission p) {

    boolean result = super.implies(p);

    return result;

  }

}

REM Since Larry is the user that owns MyPermission, Larry connects to 

REW the database to assign permissions for MyPermission.

connect larry/larry


REM As the owner of MyPermission, Larry grants himself the right to

REM administer permissions for test.larry.MyPermission within the JVM

REM security PolicyTable. Only the owner of the user-defined permission 

REM can grant administrative rights.

call dbms_java.grant_policy_permission('LARRY', 'LARRY',    'test.larry.MyPermission', '*');


REM commit the changes to the PolicyTable

commit;

REM Since Larry is the user that creates MyPermission, Larry connects to 

REW the database to assign permissions for MyPermission.

connect larry/larry


REM Once able to modify the PolicyTable for MyPermission, Larry grants himself 

REM full permission for MyPermission. Notice that the Permission is prepended 

REM with its owner schema. 

call dbms_java.grant_permission( 'LARRY',        'LARRY:test.larry.MyPermission', '*', null);


REM Larry grants Dave permission to do any actions that start with 'act.*'.

call dbms_java.grant_permission

        ('DAVE', 'LARRY:test.larry.MyPermission', 'act.*', null);


REM commit the changes to the PolicyTable

commit;

package test.larry;

import java.security.AccessController;

import java.security.Permission;

import java.security.PrivilegedAction;


import java.sql.Connection;

import java.sql.SQLException;


/**

 * MyActions is a class with a variety of public methods that

 * have some security risks associated with them. We will rely

 * on the Java security mechanisms to ensure that they are

 * performed only by code that is authorized to do so.

 */


public class Larry {


  private static String secret = "Larry's secret";

  MyPermission sensitivePermission = new MyPermission("sensitive");


  /**

   * This is a security sensitive operation. That is it can

   * compromise our security if it is executed by a "bad guy".

   * Only larry has permission to execute sensitive.

   */

  public void sensitive() {

    checkPermission(sensitivePermission);

    print();

  }


  /**

   * Will print a message from Larry.  We need to be

   * careful about who is allowed to do this

   * because messages from Larry may have extra impact.

   * Both larry and dave have permission to execute act.

   */

public void act(String message) {

    MyPermission p = new MyPermission("act." + message);

    checkPermission(p);

    System.out.println("Larry says: " + message);

  }


  /**

   * Print our secret key

   * No permission check is made; anyone can execute print.

   */

  private void print() {

    System.out.println(secret);

  }


  /**

   * Print "Hello"

   * This method invokes doPrivileged, which makes the method run

   * under definer's rights. So, this method runs under Larry's 

   * rights, so anyone can execute hello. Only Larry can execute hello

   */

  public void hello() {

    AccessController.doPrivileged(new PrivilegedAction() {

      public Object run() { act("hello"); return null; }

    });

  }


  /**

   * If a security manager is installed ask it to check permission

   * otherwise use the AccessController directly

   */

  void checkPermission(Permission permission) {

    SecurityManager sm = System.getSecurityManager();

    sm.checkPermission(permission);

  }

}

9.2.2.4 Enabling or Disabling Permissions

Once you have created a row that defines a Permission, you can disable it so that it is no longer applied. However, if you decide you want the row action again, you can enable the row. You can delete the row from the table if you believe that it will never be used again. To delete, you must first disable the row. If you do not disable the row, the deletion will not occur.

To disable rows, you can use either the disable_permission or the revoke method.

• The revoke_permission method takes in parameters similar to the grant and restrict methods. It searches the entire policy table for all rows that match the supplied parameters.

• The disable_permission method disables only a single row within the policy table. To do this, it takes in the policy table key. This key is also necessary to enable or delete a Permission. To retrieve the Permission key number, perform one of the following:

  • Save the key when it is returned on the grant or limit calls. If you do not foresee a need to ever enable or disable the Permission, you can use the grant and limit calls that do not return the Permission number.

  • View DBA_JAVA_POLICY or USER_JAVA_POLICY for the appropriate Permission key number.

Disabling Permissions using DBMS_JAVA:

procedure revoke_permission(permission_schema varchar2, 

 permission_type varchar2,       permission_name varchar2,       permission_action varchar2)


procedure disable_permission(key number)

Disabling Permissions using Java:

void revoke(String schema, String type, String name, String action);


void oracle.aurora.rdbms.security.PolicyTableManager.disable(long number);

Enabling Permissions using DBMS_JAVA:

procedure enable_permission(key number)

Enabling Permissions using Java:

void oracle.aurora.rdbms.security.PolicyTableManager.enable(long number);

Deleting Permissions using DBMS_JAVA:

procedure delete_permission(key number)

Deleting Permissions using Java:

void oracle.aurora.rdbms.security.PolicyTableManager.delete(long number);

9.2.2.5 Permission Types

Table 9-2 lists the installed Permission types. Whenever you want to grant or limit a Permission, you must provide the Permission type within the DBMS_JAVA method. The Permission types with which you control access are the following:

• Oracle-provided Permission types listed in Table 9-2

• user created Permission types that extend java.security.Permission

All the Java Permission types are documented in the Sun Microsystems Java 2 documentation.

The Oracle-specific Permissions, PolicyTablePermission and JServerPermission, are described below:

9.2.2.6 Initial Permission Grants

When you first initialize OracleJVM, several roles are populated with certain Permission grants. The following tables show these roles and their initial Permissions:

1. The JAVA_ADMIN role is given access to modify the policy table for all Permissions. All DBAs, including SYS, are granted JAVA_ADMIN. Full administrative rights to update the policy table are granted for the following Permissions:

   java.util.PropertyPermission

   java.io.SerializablePermission

   java.io.FilePermission

   java.net.NetPermission

   java.net.SocketPermission

   java.lang.RuntimePermission

   java.lang.reflect.ReflectPermission

   java.security.SecurityPermission

   oracle.aurora.rdbms.security.PolicyTablePermission

   oracle.aurora.security.JServerPermission

2. In addition to the JAVA_ADMIN Permissions, SYS is also granted the following Permissions:

   
   

   Note: Within the RuntimePermission grants, there seems to be unnecessary granting of more specific Permission for loadlibrary.<package>. The reason for this is to override the limitation given to PUBLIC for loadLibrary.*.

3. All users are initially granted the following Permissions. For the JServerPermission, all users can load classes, except for the list of classes specified in the table. These exceptions are limitation Permissions. For more information on limitation Permissions, see Example 9-2.

9.2.2.7 General Permission Definition Assigned to Roles

In release 8.1.5, Oracle8i JVM security was controlled by granting the roles of JAVASYSPRIV, JAVAUSERPRIV, or JAVADEBUGPRIV to schemas. In the current version, these roles still exist as Permission groups. See the previous section, "Initial Permission Grants" for the explicit Permissions set for each role. You can set up and define your own collection of Permissions. Once defined, you can grant any collection of Permissions to any user. That user will then have the same Permissions that exist within the role. In addition, if you need additional Permissions, you can add individual Permissions to either your specified user or role. Permissions defined within the policy table have a cumulative effect. See "Fine-Grain Definition for Each Permission" for information on how to grant Permissions to a user or a role.

The following example gives Larry and Dave the following Permissions:

• Larry receives JAVASYSPRIV Permissions.

• Dave receives JAVADEBUGPRIV Permissions and the ability to read and write all files on the system.

REM Granting Larry the same permissions as exist within JAVASYSPRIV 

grant javasyspriv to larry;


REM Granting Dave the ability to debug

grant javadebugpriv to dave;


commit;


REM I also want Dave to be able to read and write all files on the system

call dbms_java.grant_permission('DAVE', 'SYS:java.io.FilePermission',

 '<<ALL FILES>>', 'read,write', null);