Configure Oracle fine-grained access control for network services

Most Oracle databases don't need access to the network. So creating Oracle fine-grained access control for network services will help security.

Oracle has focused on increased security for several years, and Oracle Database 11g in particular was packed with several features intended to harden the database against attacks. The new Oracle fine-grained access control to network services is designed to make it more difficult for malicious individuals to use capabilities built into the Oracle database as a means to launch attacks through network services.

There are several PL/SQL utility packages in Oracle that allow users to access network services. These include the UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP and UTL_INADDR packages. By default, when the database is installed, these packages are created with the EXECUTE privilege granted to PUBLIC. Prior to 11g, this effectively meant that every user that could connect to Oracle had unlimited access to those network services. In 10g and earlier releases, if an attacker gains illicit access to any database account, they will be able to make use of these capabilities. In 11g, the default setting for Oracle fine-grained access control prohibits access to these network services. Code that uses one or more of these packages to make network calls will generate an error. Database administrators have the ability to grant access to network services at a very granular level to the accounts that need it. When the network services are available to only a handful of accounts, the potential for a security breach is greatly reduced.

Oracle fine-grained access control to network services is configured through the use of an access control list (ACL) that is stored in Oracle XML DB. ACL lists define which users have access to network services and specifically what services are available to them. It is possible to use Oracle XML DB to create an access control list. However, more commonly, ACLs are created using procedures in the DBMS_NETWORK_ACL_ADMIN and DBMS_NETWORK_ACL_UTILITY PL/SQL packages.

Creating an access control list

There are some basic steps to create an access control list with the DBMS_NETWORK_ACL_ADMIN package. First, an Access Control List and its privilege definitions must be created using the CREATE_ACL procedure:

    acl        => 'file_name.xml',
    description => 'file description',
    principal   => 'user_or_role',
    is_grant    => TRUE|FALSE,
    privilege   => 'connect|resolve',
    start_date  => null|timestamp_with_time_zone,
    end_date    => null|timestamp_with_time_zone);

The parameters supplied to the CREATE ACL procedure are the following:

  • acl -- This is the filename to be used for the access control list XML file.
  • description -- This is a brief description of the purpose of the file.
  • principal – This is the initial user account or role being granted (or denied) permissions.
  • is_grant – This must be either TRUE or FALSE, to indicate whether the privilege is to be granted or denied.
  • privilege – This can be either connect or resolve. Connect grants permission to connect to a network service. Resolve grants the user permission to resolve a network host name or an IP address. Connect is the higher-level privilege and includes resolve.
  • start_date -- This is the (optional) starting date that the entry will be valid.
  • end_date --This is the (optional) ending date that the entry will be valid.

Once the ACL exists, you can add additional users or roles to it or grant additional privileges to one user or role via the ADD_PRIVILEGE procedure:

    acl        => 'file_name.xml',
    principal  => 'user_or_role',
    is_grant   => TRUE|FALSE,
    privilege  => 'connect|resolve',
    position   => null|value,
    start_date => null|timestamp_with_time_zone,
    end_date   => null|timestamp_with_time_zone);

The matching parameters that exist in ADD_PRIVILEGE and CREATE_ACL have the same meaning. The only parameter that does not exist in the CREATE_ACL procedure is position. The position parameter sets the precedence for multiple users or roles.

Once all of the necessary privileges and users have been added to the ACL, it is necessary to assign the Oracle fine-grained access control list to one or more network host computers using the ASSIGN_ACL procedure. Only a single access control list can be assigned to any host computer, domain or IP subnet and TCP port range (if specified). If there is already an access control list assigned to a given target when you issue this command, Oracle will de-assign the legacy access control list before assigning the new one:

    acl => 'file_name.xml',
    host => 'network_host',
    lower_port => null|port_number,
    upper_port => null|port_number);

The parameters for the ASSIGN_ACL procedure are:

  • acl --This is the filename of the access control list XML file.
  • host -- This is the network host to which this access control list will be assigned. The parameter can be a name or IP address of the network host, or you can enter localhost.
  • lower_port -- (Optional) For TCP connections, this is the lower boundary of the port range. Use this setting for the connect privilege only; omit it for the resolve privilege. The default is null, which means that there is no port restriction (that is, the ACL applies to all ports).
  • upper_port -- (Optional) For TCP connections, enter the upper boundary of the port range. Use this setting for connect privileges only; omit it for resolve privileges. The default is null.

Very few accounts in an Oracle database really need access to network services. When creating Oracle fine-grained access control lists, you should try to make them as restrictive as possible to get the maximum security benefit. Inexperienced administrators will simply create an ACL that provides the same wide open access that exists in 10g. This is easy to do. It is also low maintenance, since there will never be a need to add new accounts or privileges when requirements change. However, it also means that the database has a huge security hole. As a responsible DBA, you should learn enough about this feature to be able to make use of it properly.

Dig Deeper on Oracle database security