10 Security for Oracle Database Java Applications

Fine-Grain Definition for Each Permission

Using fine-grain definition, you can grant each permission individually to specific users or roles. If you do not grant a permission for access, then the schema will be denied access. To set individual permissions within the policy table, you must provide the following information:

You can grant permissions using either SQL or Java. Each version 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.

After running the grant, if a row already exists for the exact permission, then no update occurs, but the key for that row is returned. If the row was disabled, then running the grant enables the existing row.

/private/oracle/*

/private/oracle/-

You can grant permissions using the DBMS_JAVA package, as follows:

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)

You can grant permissions using Java, as follows:

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);

You can limit permissions using the DBMS_JAVA package, as follows:

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)

You can limit permissions using Java, as follows:

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);

Example 10-1 shows how to use the grant_permission() method to grant permissions. Example 10-2 shows how to limit permissions using the restrict() method.

connect larry
Enter password: password

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 PolicyTable
commit;

Example 10-2 Limiting Permissions

You can use the restrict() method to specify a limitation or exception to general rules. A general rule is a rule where, in most cases, the permission is true or granted. However, there may be exceptions to this rule. For these exceptions, you specify a limitation permission.

If you have defined a general rule that no one can read or write an entire directory, then you can define a limitation on an aspect of this rule through the restrict() method. For example, if you want to allow access to all files within the /tmp directory, except for your password file that exists in that directory, then you would grant permission for read and write to all files within /tmp and limit read and write access to the password file.

If you want to specify an exception to the limitation, then you must create an explicit grant permission to override the limitation permission. In the previously mentioned scenario, if you want the file owner to still be able to modify the password file, then you can grant a more explicit permission to allow access to one user, which will override the limitation. Oracle JVM security combines all rules to understand who really has access to the password file. This is demonstrated in the following diagram:

Description of the illustration limitper.gif

The explicit rule is as follows:

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

The following code implements this example:

connect larry
Enter password: password

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;

The preceding code performs the following actions:

1. Grants everyone read and write permission to all files in /tmp.

2. Limits everyone from reading or writing only the password file in /tmp.

3. Grants only Larry explicit permission to read and write the password file.

Acquiring Administrative Permission to Update Policy Table

All permissions are rows in PolicyTable. Because it is a table in the database, you need appropriate permissions to modify it. Specifically, the PolicyTablePermission object is required to modify the table. After initializing Oracle JVM, only a single role, JAVA_ADMIN, is granted PolicyTablePermission to modify PolicyTable. The JAVA_ADMIN role is immediately assigned to the database administrator (DBA). Therefore, if you are assigned to the DBA group, then you will automatically take on all JAVA_ADMIN permissions.

If you need to add permissions as rows to this table, JAVA_ADMIN must grant your schema update rights using PolicyTablePermission. This permission defines that your schema can add rows to the table. Each PolicyTablePermission is for a specific type of permission. For example, to add a permission that controls access to a file, you must have PolicyTablePermission that lets you grant or limit a permission on FilePermission. Once this occurs, you have administrative permission for FilePermission.

An administrator can grant and limit PolicyTablePermission in the same manner as other permissions, but the syntax is complicated. For ease of use, you can use the grant_policy_permission() or grantPolicyPermission() method to grant administrative permissions.

You can grant policy table administrative permission using DBMS_JAVA, as follows:

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 )

You can grant policy table administrative permission using Java, as follows:

long oracle.aurora.rdbms.security.PolicyTableManager.grantPolicyPermission (java.lang.String grantee, java.lang.String permission_schema,
 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_schema, 
java.lang.String permission_type, java.lang.String permission_name, long[] key);

Example 10-3 shows how you can modify PolicyTable.

REM Connect as SYS, which is assigned JAVA_ADMIN role, to give Larry permission
REM to modify the PolicyTable
connect SYS as SYSDBA
Enter password: password

REM SYS grants Larry the right to administer permissions for
REM FilePermission
call dbms_java.grant_policy_permission('LARRY', 'SYS', 'java.io.FilePermission', '*');

Creating Permissions

You can create your own permission type by performing the following steps:

1. Create and load the user permission

   Create your own permission by extending the java.security.Permission class. Any user-defined permission must extend Permission. The following example creates MyPermission, which extends BasicPermission, which, in turn, extends 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;
     }
   }
   

2. Grant administrative and action permissions to specified users

   When you create a permission, you are designated as the owner of that permission. The owner is implicitly granted administrative permission. This means that the owner can be an administrator for this permission and can run grant_policy_permission(). Administrative permission enable the user to update the policy table for the user-defined permission.

   For example, if LARRY creates a permission, MyPermission, then only he can call grant_policy_permission() for himself or another user. This method updates PolicyTable on who can grant rights to MyPermission. The following code demonstrates this:

   REM Since Larry is the user that owns MyPermission, Larry connects to
   REW the database to assign permissions for MyPermission.
   connect larry
   Enter password: password
   
   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 PolicyTable
   commit;
   

   Once you have granted administrative rights, you can grant action permissions for the created permission. For example, the following SQL statements grant LARRY the permission to run anything within MyPermission and DAVE the permission to run only actions that start with "act.".

   REM Since Larry is the user that creates MyPermission, Larry connects to
   REW the database to assign permissions for MyPermission.
   connect larry
   Enter password: password
   
   REM Once able to modify PolicyTable for MyPermission, Larry grants himself
   REM full permission for MyPermission. Notice that the Permission is prefixed
   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 PolicyTable
   commit;
   

3. Implement security checks using the permission

   Once you have created, loaded, and assigned permissions for MyPermission, you must implement the call to SecurityManager to have the permission checked. There are four methods in the following example: sensitive(), act(), print(), and hello(). Because of the permissions granted using SQL in the preceding steps, the following users can run methods within the example class:

   • LARRY can run any of the methods.

   • DAVE is given permission to run only the act() method.

   • Anyone can run the print() and hello() methods. The print() method does not check any permissions. As a result, anyone can run it. The hello() method runs AccessController.doPrivileged(), which means that the method runs with the permissions assigned to LARRY. This is referred to as the definer's rights.

   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 display a message from Larry. You must 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);
     }
   
   /**
   * display secret key
   * No permission check is made; anyone can execute print.
   */
     private void print()
     {
       System.out.println(secret);
     }
   
   /**
   * Display "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);
     }
   }
   

Enabling or Disabling Permissions

Once you have created a row that defines a permission, you can disable it so that it no longer applies. However, if you decide that you want the row action again, then 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, then the deletion will not occur.

To disable rows, you can use either of the following methods:

• revoke_permission()

  This method accepts parameters similar to the grant() and restrict() methods. It searches the entire policy table for all rows that match the parameters provided.

• disable_permission()

  This method disables only a single row within the policy table. To do this, it accepts the policy table key as parameter. 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, then you can use the grant and limit calls that do not return the permission number.

  • Look up DBA_JAVA_POLICY or USER_JAVA_POLICY for the appropriate permission key number.

You can disable permissions using DBMS_JAVA, as follows:

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

procedure disable_permission (key number)

You can disable permissions using Java, as follows:

void oracle.aurora.rdbms.security.PolicyTableManager.revoke (java.lang.String grantee, java.lang.String permission_type,
 java.lang.String permission_name, java.lang.String permission_action_type);

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

You can enable permissions using DBMS_JAVA, as follows:

procedure enable_permission (key number)

You can enable permissions using Java, as follows:

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

You can delete permissions using DBMS_JAVA, as follows:

procedure delete_permission (key number)

You can delete permissions using Java, as follows:

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

Permission Types

Whenever you want to grant or limit a permission, you must provide the permission type. The permission types with which you control access are the following:

• Java 2 permission types

• Oracle-specific permission types

• User-defined permission types that extend java.security.Permission

Table 10-1 lists the installed permission types.

The Oracle-specific permissions are:

• oracle.aurora.rdbms.security.PolicyTablePermission

  This permission controls who can update the policy table. Once granted the right to update the policy table for a certain permission type, you can control the access to few resources.

  After the initialization of Oracle JVM, only the JAVA_ADMIN role can grant administrative rights for the policy table through PolicyTablePermission. Once it grants this right to other users, these users can, in turn, update the policy table with their own grant and limitation permissions.

  To grant policy table updates, you can use the grant_policy_permission() method, which is in the DBMS_JAVA package. Once you have updated the table, you can view either the DBA_JAVA_POLICY or USER_JAVA_POLICY view to see who has been granted permissions.

• oracle.aurora.security.JServerPermission

  This permission is used to grant and limit access to Oracle JVM resources. The JServerPermission extends BasicPermission. The following table lists the permission names for which JServerPermission grants access:

  Table 10-2 JServerPermission Description

  Grantee	Permission Type	Permission Name	Permission Granted or Restricted	Action
  JAVADEBUGPRIV	SYS:oracle.aurora.security.JServerPermission	Debug	Granted	null
  SYS	SYS:oracle.aurora.security.JServerPermission	*	Granted	null
  SYS	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.java.*	Granted	null
  SYS	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.oracle.aurora.*	Granted	null
  SYS	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.oracle.jdbc.*	Granted	null
  PUBLIC	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.*	Granted	null
  PUBLIC	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.java.*	Restricted	null
  PUBLIC	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.oracle.aurora.*	Restricted	null
  PUBLIC	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.oracle.jdbc.*	Restricted	null
  JAVA_DEPLOY	SYS:oracle.aurora.security.JServerPermission	LoadClassInPackage.oracle.aurora.deploy.*	Granted	null
  JAVA_DEPLOY	SYS:oracle.aurora.security.JServerPermission	Deploy	Granted	null

  
  

Initial Permission Grants

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

• Table 10-3, "SYS Initial Permissions"

• Table 10-4, "PUBLIC Default Permissions"

• Table 10-5, "JAVAUSERPRIV Permissions"

• Table 10-6, "JAVASYSPRIV Permissions"

• Table 10-7, "JAVADEBUGPRIV Permissions"

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 permissions listed in Table 10-1. In addition to the JAVA_ADMIN permissions, SYS is granted some additional permissions that are needed to support the standard JDK functionality and Oracle JVM specifics.

Table 10-3 lists some of the additional permissions granted to SYS.

Table 10-4 lists permissions initially granted or restricted to all users.

Table 10-5 lists permissions initially granted to the JAVAUSERPRIV role.

Table 10-6 lists permissions initially granted to the JAVASYSPRIV role.

Table 10-7 lists permissions initially granted to the JAVADEBUGPRIV role.

General Permission Definition Assigned to Roles

In Oracle8i Database release 8.1.5, Oracle JVM security was controlled by granting the JAVASYSPRIV, JAVAUSERPRIV, or JAVADEBUGPRIV role to schemas. In Oracle Database 12c Release 1 (12.1), these roles still exist as permission groups. You can set up and define your own collection of permissions. Once defined, you can grant any collection of permissions to any user or role. That user will then have the same permissions that exist within the role. In addition, if you need additional permissions, then you can add individual permissions to either your specified user or role. Permissions defined within the policy table have a cumulative effect.

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 those existing 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);