Applied Oracle Security: Developing Secure Database and Middleware Environments- P19 doc

Rule Set Function Description DVSYS.DV_SYSEVENT Returns the system event firing the rule set, in VARCHAR2 data type; the event name is the same as the syntax found in the SQL statement

The DBV rules engine had created DBV rule that references this PL/SQL function When the function was dropped, the reference was broken along with the underlying GRANT EXECUTE privilege on the function to DVSYS We can see this problem by attempting to validate the correct syntax of all the DBV rules that are configured We can perform this validation by issuing the following call as the DBV security administrator (DBVOWNER):

dbvowner@aos> exec dbms_macadm.sync_rules;

BEGIN dbms_macadm.sync_rules; END;

*

ERROR at line 1:

ORA-25448: rule DVSYS.DV$5045 has errors

ORA-00904: "SH"."CAN_PERFORM_SALES_SUMMARY": invalid identifier

ORA-06512: at "SYS.DBMS_RULE_ADM", line 188

ORA-06512: at "DVSYS.DBMS_MACADM", line 2794

ORA-06512: at line 1

In this example, you can see that one of our rules is invalid, probably because we forgot to GRANT EXECUTE privilege on a function to DVSYS You can isolate the offending rule by querying the DVSYS.DV$RULE view as follows:

dbvowner@aos>SELECT name,rule_expr

from dvsys.dv$rule

WHERE id# = 5045;

NAME RULE_EXPR

-

-Is Sales Summary Allowed sh.can_perform_sales_summary = 1

1 row selected.

In this example, the internal rule name is DVSYS.DV$5045 This corresponds to the ID# = 5045

in the view DVSYS.DV$RULE The DBV security administrator can investigate views such as DBA_TAB_PRIVS and DBA_OBJECTS to determine why the problem exists In this case, if MARY simply re-creates the function and GRANTs EXECUTE privilege on the function to DVSYS, the DBV security administrator can then reexecute the DBMS_MACADM.SYNC_RULES procedure to recompile the DBV rule

DBV Rule Set Event Functions

The DBV product installs a collection of PL/SQL functions that can be used in DBV rule

expressions to retrieve detailed information about the database command that is being evaluated for realm authorizations and command rules—such as UPDATE on SH.TABLE—as well as the session context in which the command is operating These PL/SQL functions are called the DBV rule set event functions Table 5-1 describes these functions

We can use these event functions directly in our DBV Rule expressions—for example, testing for a list of values:

dbvowner@aos> BEGIN

dbms_macadm.create_rule(

rule_name => 'Trusted Sales Administrators'

, rule_expr => 'DVSYS.DV_LOGIN_USER IN (''ANTHONY'',''MARY'')'

);

END;

/

PL/SQL procedure successfully completed.

We can even use SQL subqueries and these event functions directly in our DBV rule

expressions For example, if we want to test to see that the session user is a member of the

IT department as defined in the Human Resources schema, we’d use this:

dbvowner@aos> BEGIN

dbms_macadm.create_rule(

rule_name => 'Works In The IT Department'

, rule_expr => '(SELECT COUNT(*) FROM hr.employees where email =

|| ' DVSYS.DV_LOGIN_USER AND department = 60) > 0'

);

END;

/

PL/SQL procedure successfully completed.

Rule Set Function Description

DVSYS.DV_SYSEVENT Returns the system event firing the rule set, in VARCHAR2 data

type; the event name is the same as the syntax found in the SQL statement that is issued, for example, INSERT, CREATE

DVSYS.DV_DICT_OBJ_TYPE Returns the type of the dictionary object on which the database

operation occurred, for example, table, procedure, view; the return type is VARCHAR2

DVSYS.DV_DICT_OBJ_OWNER Returns the owner of the dictionary object on which the

database operation occurred; the return type is VARCHAR2 DVSYS.DV_DICT_OBJ_NAME Returns the name of the dictionary object on which the

database operation occurred; the return type is VARCHAR2 DVSYS.DV_SQL_TEXT Returns the first 4000 characters of SQL text of the database

statement used in the operation; the return type is VARCHAR2 DVSYS.DV_LOGIN_USER Returns the login user name, in VARCHAR2 data type; returns

the same value that SYS_CONTEXT(‘USERENV’, ‘SESSION_ USER’) returns

DVSYS.DV_INSTANCE_NUM Returns the database instance number, in NUMBER data type DVSYS.DV_DATABASE_NAME Returns the database name, in VARCHAR2 data type

TABLE 5-1 DBV Rule Set Event Functions

DBV Factors Used in Rule Set Expressions

In the rule examples we’ve demonstrated so far, most of the logic for the security decisions we’ve used is implemented in the Sales History schema (SH) for the sake of simplifying the examples While these are merely examples, we need to think about our rules from the enterprise perspective,

so that security controls are maintained outside of the application This needs to be done not only for security’s sake, but also to allow application developers to leverage corporate policies around security This is also important from the perspective of reuse, because developers and system architects should not have to reinvent or recode the same controls for each application that is being designed

DBV rules should be based on conditions from a trusted source, whether that source is internal to the database or in an external system This is where DBV factors play a role DBV factors are available as PL/SQL functions that have independent access (from the application’s perspective) to a method or data for security relevant information For example, the DBV security administrator can define DBV factors such as User Department and Connection Method The administrator can then use these factors to create additional factors, such as Sales Staff User or Secure Connection From a pseudo-code point of view, these may take the following form:

User department SELECT department

FROM hr.employees WHERE email = SYS_CONTEXT('USERENV', 'SESSION_USER') Sales staff user If DVSYS.GET_FACTOR('User Department') IN

('Retail Sales', 'Government Sales') Then 'Sales Staff User' is 'TRUE' Else 'Sales Staff User' is 'FALSE' Authentication method SYS_CONTEXT('USERENV', 'AUTHENTICATION_METHOD') Secure connection If DVSYS.GET_FACTOR('Authentication Method')

IN ('SSL', 'KERBEROS') AND DVSYS.GET_FACTOR('Client IP') LIKE '192.168.0.%'

Then 'Secure Connection' is 'TRUE' Else 'Secure Connection’ is 'FALSE'

Application developers do not always need to be concerned about the implementation of the information used to establish the DBV factors In some cases, you may not want them to know! For example, the User Department could just as easily come from an external LDAP source, such

as Oracle Internet Directory (OID) or a web service Each database application developer or architect should not have to consider how the factor is resolved They simply need to know what the factor means and how it applies to their applications The point here is that factors of security-relevant attributes can be shared by more than one application and are maintained by the security administrator, a third party with respect to the application developers and application DBAs These factors can form the building blocks in DBV rule sets that may be applied to more than one application

We’ve discussed how DBV factors provide many advantages to applications, including security controls that can be shared across applications and logic that is maintained outside

of application development control The ability to use them in DBV rule sets provides a more

verifiable and readable security policy for compliance In the next section, we will dig into the details

of DBV factor configuration and the component’s powerful features that offer information assurance

Factors

DBV factors are security relevant attributes that help to establish the context for a session to authorize database commands or actions, such as the following (shown in Figure 5-10):

Connecting to the database, or a session authorization, when used as part of a DBV CONNECT command rule

Executing a (SQL) command statement on a database object or a statement level

authorization when used as part of a DBV command rule or realm authorization

Filtering data in SELECT and DML statements, or a row-level security (RLS) authorization, when used in Oracle Virtual Private Database (VPD) policy or the Oracle DBV Oracle Label Security (OLS) integration

Branching in application code, or logic authorizations, when using the DBV factor

function or the GET_FACTOR function in PL/SQL logic

DBV factors are typically defined and maintained outside of specific database applications Factors can use information that may be internal or external to the information stored in the database DBV factors are used primarily to establish the context of the “subject” (who) in your security policy and the “conditions” in your security policy (when, how, where) The context of the subject may include session information on roles granted, group/organizational membership, privileges granted, and even identity management related attributes, such as job title Conditional attributes may include information such as time of day or month, authentication method used, database client location,

or access path (recall the trusted package example) to the enforcement point The 11.0.6 DBV installation will create 17 factors that may be useful for your organization’s security policy

■

■

■

■

FIGURE 5-10 DBV factor usage

Creating Factors

The fundamental configuration of a DBV factor is the factor name and the PL/SQL expression

used to retrieve the factor’s value, or the factor’s identity as it is called One factor that is installed

by DBV is Client IP, which is the database client’s IP address The factor uses the PL/SQL

expression UPPER(SYS_CONTEXT(‘USERENV’,’IP_ADDRESS’)) to retrieve its identity To define

your own retrieval-based custom factor you would follow these steps:

1 Define the factor’s retrieval method using a PL/SQL function.

2 Grant EXECUTE privileges on this PL/SQL function to the DVSYS account.

3 Define the factor definition as the DBV security administrator (DBVOWNER).

Factor Retrieval Method

The factor retrieval method is a PL/SQL expression or SQL SELECT statement that returns a single VARCHAR2 value PL/SQL expressions can be based on PL/SQL functions or SQL built-in functions defined by the Oracle RDBMS, or they can be based on a custom PL/SQL function that you’ve built The key is that the function returns a VARCHAR2 value even if it is NULL, or it returns some data type that can be cast to a VARCHAR2 by typical Oracle data type casting rules The function’s signature can be defined as follows:

FUNCTION some_factor RETURN VARCHAR2;

or FUNCTION another_factor(param1 IN data_type1 … paramN IN data_typeN)

RETURN VARCHAR2;

Note in the latter signature that it is possible to pass parameters to your factor function if you need additional information not readily available to the PL/SQL logic inside the function or if you need

to integrate existing functions and cannot change the function’s signature Consider the following custom PL/SQL package that retrieves department information for users stored in the Human Resources (HR) object owner account:

hr@aos> define the package specification

hr@aos> CREATE OR REPLACE PACKAGE hr.employee_utility IS

FUNCTION get_user_department_id ( user_name IN

VARCHAR2 DEFAULT SYS_CONTEXT('USERENV', 'SESSION_USER') ) RETURN NUMBER; FUNCTION get_user_department_name ( user_name IN

VARCHAR2 DEFAULT SYS_CONTEXT('USERENV', 'SESSION_USER') ) RETURN VARCHAR2; END;

/

Package created.

hr@aos> define the package body

hr@aos> CREATE OR REPLACE PACKAGE BODY hr.employee_utility IS

FUNCTION get_user_department_id ( user_name IN

VARCHAR2 ) RETURN NUMBER IS

l_email VARCHAR2(120);

l_dept_id hr.employees.department_id%TYPE;

BEGIN

input parameter checking

IF user_name IS NULL OR LENGTH(user_name) > 100 THEN

RAISE_APPLICATION_ERROR(-20001,

'Invalid parameter for "user_name"',FALSE);

END IF;

database usernames and email names are similar

l_email := user_name;

query the employee's department assignment

SELECT department_id

INTO l_dept_id

FROM hr.employees

WHERE email = l_email;

RETURN l_dept_id;

EXCEPTION

WHEN NO_DATA_FOUND THEN

RETURN NULL;

END;

FUNCTION get_user_department_name ( user_name IN

VARCHAR2 ) RETURN VARCHAR2 IS

l_dept_id hr.employees.department_id%TYPE;

l_dept_name hr.departments.department_name%TYPE;

BEGIN

l_dept_id := get_user_department_id(user_name);

IF l_dept_id IS NULL THEN

RETURN NULL;

END IF;

SELECT department_name

INTO l_dept_name

FROM hr.departments

WHERE department_id = l_dept_id;

RETURN l_dept_name;

EXCEPTION

WHEN NO_DATA_FOUND THEN

RETURN NULL;

END;

END;

/

Package created.

In these PL/SQL examples, a table named HR.EMPLOYEES and the employees listed in this table may also have database accounts We can match the database account names to the EMAIL column of the HR.EMPLOYEES table, without the @company suffix The two functions in this package can retrieve department assignment information, such as the department ID or department name for the employee To use custom-developed PL/SQL functions in DBV factors, your next step is to GRANT EXECUTE privilege on the package or function to the DVSYS account as follows:

hr@aos> GRANT EXECUTE ON hr.employee_utility TO dvsys;

Grant succeeded.

When custom-developed PL/SQL functions, such as those defined in the example package, are used as the retrieval method for DBV factors, the function is typically defined with definer’s rights, versus invoker’s rights The factor retrieval method may involve the use privileges on database objects or other PL/SQL code The encapsulation of the factor retrieval methods in PL/SQL packages and their internal functions avoids the need to maintain additional privilege grants to

the DVSYS account With the GRANTS to DVSYS in place, the DBV security administrator can define the factor definitions that make use of the PL/SQL package functions:

dbvowner@aos> user department identifier

dbvowner@aos> BEGIN

dbms_macadm.create_factor(

factor_name => 'User_Department_Id',

factor_type_name => 'User',

description =>

'The identifier of the department the current user works in.',

rule_set_name => NULL ,

get_expr => 'hr.employee_utility.get_user_department_id',

validate_expr => NULL,

identify_by => dbms_macutl.g_identify_by_method,

labeled_by => dbms_macutl.g_labeled_by_self,

eval_options => dbms_macutl.g_eval_on_access,

audit_options => dbms_macutl.g_audit_on_get_error,

fail_options => dbms_macutl.g_fail_with_message);

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos> user department name

dbvowner@aos> BEGIN

dbms_macadm.create_factor(

factor_name => 'User_Department_Name' ,

factor_type_name => 'User',

description =>

'The name of the department the current user works in.',

rule_set_name => NULL ,

get_expr =>

'hr.employee_utility.get_user_department_name',

validate_expr => NULL,

identify_by => dbms_macutl.g_identify_by_method,

labeled_by => dbms_macutl.g_labeled_by_self,

eval_options => dbms_macutl.g_eval_on_access,

audit_options => dbms_macutl.g_audit_on_get_error,

fail_options => dbms_macutl.g_fail_with_message);

END;

/

PL/SQL procedure successfully completed.

The DBMS_MACADM package that is used for factor creation allows for the factor retrieval

method parameter, get_expr, to use a function that returns a VARCHAR2, as is the case with the function HR.EMPLOYEE_UTILITY.GET_USER_DEPARTMENT_NAME or a function that can be cast to a VARCHAR2 value, as is the case with the function HR.EMPLOYEE_UTILITY.GET_USER_ DEPARTMENT_ID.

The following example demonstrates how to use a SQL SELECT statement to retrieve a factor value with a query on the V$DATABASE view for the OS platform on which the database is running:

dbvowner@aos> BEGIN

dbms_macadm.create_factor(

factor_name => 'Platform_Name' ,

factor_type_name => 'Instance',

description => 'Retrieves the OS Platform the

database is running on',

rule_set_name => NULL ,

get_expr => '(SELECT platform_name FROM v$database)',

validate_expr => null,

identify_by => dbms_macutl.g_identify_by_method,

labeled_by => dbms_macutl.g_labeled_by_self,

eval_options => dbms_macutl.g_eval_on_session,

audit_options => dbms_macutl.g_audit_on_get_error,

fail_options => dbms_macutl.g_fail_with_message);

END;

/

PL/SQL procedure successfully completed.

When using SQL SELECT statements, you must embed the SELECT statement in parentheses and the DVSYS account must be granted SELECT privileges on the table or view being queried

Naming Factors

It is important that you name your factors with identifiers that convey the attribute retrieved, in human readable form, to improve the readability of your DBV policy where these factors are used In other words, using readable factor names such User_Department_Name, compared to the names used for variables or columns, such as USR_DEPT, improves readability of the security policy when a factor is used in a DBV rule set expression Here’s an example:

dbvowner@aos> BEGIN

dbms_macadm.create_rule(

rule_name => 'Is An Employee of the IT Department'

, rule_expr =>

'DVSYS.GET_FACTOR(''User_Department_Name'') = ''IT'''

);

END;

PL/SQL procedure successfully completed.

Scope of Factor Retrieval Method

It is important that you test the factor function by executing it using the DVSYS account and several test accounts to determine whether the factor retrieval method raises exceptions for any database sessions You must consider whether the session contextual information on which the factor function may rely is defined for each account you test, and you should handle these cases in the code that makes up the factor function You should deal with these conditions because once factor functions are defined, they are evaluated at session establishment for every session, even those running as part of the Oracle RDBMS product, such as Enterprise Manager Database Control jobs DBV factors do not currently have a scoping mechanism to limit their evaluation to certain

accounts, roles, or session conditions, so if you want to prevent processing in the factor logic for certain types of sessions, you will need to codify this in your PL/SQL factor function With our department example, Oracle database accounts such as SYS, SYSTEM, and SYSMAN, to name a few, will not exist in the HR table records, so we simply return NULLS to handle these cases

Factor Evaluation The eval_options parameter in the DBMS_MACADM.CREATE_FACTOR

procedure controls when the identity of the factor should be resolved by calling the factor retrieval method A factor identity can be resolved just once, at the time the database session is started, using the constant DBMS_MACUTL.G_EVAL_ON_SESSION With this constant, the factor retrieval method

is called once when the database session is established and cached in the database session context namespace MAC$FACTOR Subsequent calls to resolve the identity are read from this read-only memory area to improve performance If the constant DBMS_MACUTL.G_EVAL_ON_ACCESS is used for this parameter, each call to resolve the factor’s identity will call the factor’s retrieval method

In our examples so far, factors such as AUTHENTICATION_METHOD or CLIENT_IP will not change over the course of a database session, so identity resolution should be configured using DBMS_ MACUTL.G_EVAL_ON_SESSION Factors such as User_Department_Name and User_Department_

Id could in fact change during the course of a database session (if the employee were reassigned, for example), so the parameter DBMS_MACUTL.G_EVAL_ON_ACCESS should be used

TIP

Use the evaluation on access for the factor retrieval method if the

values can change over the course of a database session.

Factor Auditing

It is possible that the PL/SQL expression used in the DBV factor’s retrieval method (the get_expr

parameter) can encounter some error in processing or return a NULL value The DBV factor

can be configured to audit these outcomes using the audit_options parameter in the DBMS_

MACADM.CREATE_FACTOR procedure The DVA web application allows the DBV security administrator to query these audit records using a standard report that is provided with the application

Factor Functions

When a factor is created, the DBV product will create a PL/SQL function of the form, DVF.

F$<FactorName>, that can be used in DBV rule set expressions or your own PL/SQL code When

we created the factor User_Department_Name, a function named DVF.F$USER_DEPARTMENT_ NAME was created This PL/SQL function is publicly available to all database sessions The

following demonstrates the usage of function for the User_Department_Name factor

anthony@aos>select DVF.F$USER_DEPARTMENT_NAME FROM DUAL;

F$USER_DEPARTMENT_NAME

-IT

1 row selected.

If the name of a the factor that must be used is dynamically resolved, the rule set or

application logic can use the function DVSYS.GET_FACTOR(‘FactorName’) to get the value

of the factor, as shown in the following example:

anthony@aos>select DVSYS.GET_FACTOR('USER_DEPARTMENT_NAME') FROM DUAL;

DVSYS.GET_FACTOR('USER_DEPARTMENT_NAME')

-IT

1 row selected.

Factor Identities

The term “identity” is typically defined as the unique identifier of a user stored in an identity management repository In DBV, the term is overloaded to mean the value of a factor DBV can be configured with many more security-relevant attributes than just the user when you’re defining a security policy, so you have many identities to consider We have identities (values) for the client

IP addresses, client machines, the time of day, user departments, and so on As you have seen with the examples so far, the DBV factor configuration supports the use of a simple PL/SQL

expression that uses publicly available PL/SQL functions—for example, SYS_CONTEXT or TO_ CHAR(SYSDATE)—and this can be custom PL/SQL code When we define a factor in this way, we use the constant DBMS_MACUTL.G_IDENTIFY_BY_METHOD for the parameter identify_by and place the PL/SQL expression in the get_expr parameter in the call to the DBMS_MACADM.

CREATE_FACTOR procedure

Factor Identity as a Constant

The PL/SQL expression used to establish the factor’s identity can also be a constant value We specify a constant identity using the constant DBMS_MACUTL.G_IDENTIFY_BY_CONSTANT for

the parameter identify_by and place the constant value in the get_expr parameter in the call to

the procedure DBMS_MACADM.CREATE_FACTOR A factor with a constant identity can be useful for IF/THEN/ELSE or CASE/SWITCH logic that you may include in your security policy For example, you may have a highly restrictive policy in a production database and a less restrictive policy in a development database We could define a factor such as IS_PRODUCTION to return

0 or 1, or a factor such as ENVIRONMENT_NAME to return a value such as ‘DEV’, ‘TEST’, or

‘PROD’ (separately) in each database to handle this type of scenario

Factors Identified by Other Factors

We can also identify a factor based on the identity of other factors Using this method, we can

assert the identity of a factor using a declarative DBV construct called identity maps Identity maps

allow for a multifactored security capability to be defined in your database and does not require special PL/SQL code This method of factor resolution requires the use of the constant DBMS_

MACUTL.G_IDENTIFY_BY_FACTOR for the parameter identify_by in the call to the procedure

DBMS_MACADM.CREATE_FACTOR Multifactored security is really one of the most interesting and powerful security features of DBV To illustrate this feature, consider the example discussed with the DBV CONNECT command rule, where we placed a greater level of trust in database clients that were either on the database server console itself, and those clients that authenticated to the database using an Oracle Advanced Security Option (ASO) credential mechanism, such as PKI/ SSL or Kerberos, from within the corporate network This example was an all-or-nothing type of authorization that either allowed the database connection or did not allow it The example did in fact consider multiple factors, the authentication method, and the client’s IP address We can extend this example to use the multifactored approach to classify the database connection as a DBV factor using DBV identity maps This DBV factor for the connection classification can have more than just TRUE/FALSE identity values that can be used for DBV command rules, DBV realm authorizations, VPD or OLS policies, and even your own PL/SQL logic

Let’s assume the following notional environment conditions:

We are using ASO’s PKI/SSL option for secure connections within the corporate network The corporate network (intranet) is defined by the subnet 192.168.0

■

■