CHAPTER 21 • ORACLE8i DATABASE SECURITY 958 context package; user sign-on context package seems like a more appropriate name.) The context area is an area of private memory that is unique to every session con- nected to the database. You will create placeholders in this memory area to store some values that are set at logon. Later in the process, you will read the context memory area and retrieve these stored memory areas for use. This is an optional step. You could define the context area every time the user accesses the object, but this approach is faster, because you do these checks only once. You place values into the context area by creating a package or function that is called each time users log on to the database. For this project, you will store the user’s assigned security level into a context variable whenever the user logs in. This way, you can quickly retrieve this security value from the context area when you need it. This saves multiple trips to the security table to look up the security ID each time you need that value. Before you can use a context namespace, you must first create the context name- space, which needs to be done only once for each specific context area. The context namespace is created using the CREATE CONTEXT command (or you can use CREATE OR REPLACE CONTEXT, if you prefer). When you create the context namespace, you define the package that will be used to set the values to be stored in the context namespace. Typically, when you create the context, the associated package will not have been created yet, and that’s okay. You will create that package next. NOTE Creating the context namespace is similar to programming with a pointer. You first create the pointer, and then you allocate memory to it. The same is true with a con- text. You first create the context, and then the context setting package “allocates” what is to be stored to the context. (Okay, so all comparisons have limitations!) After you have created the context area, you will use the DBMS_SESSION.SET_ CONTEXT package to store a value in a context area. This package allows you to cre- ate what amounts to variables and assign values to these variables. These variables and their assigned values are then poked into memory for quick retrieval later. The DBMS_SESSION.SET_CONTEXT procedure takes three parameters. Here is the proce- dure definition: PROCEDURE DBMS_SESSION.SET_CONTEXT ( NAMESPACE VARCHAR2, ATTRIBUTE VARCHAR2, VALUE VARCHAR2); C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 959 When you call the SET_CONTEXT procedure from your context setting package or function, you simply pass it the name of the context you want to use, the name of the context variable you wish to create, and the value you wish to store associated with that variable. When you create the application context package, this package will take one param- eter, which is the username of the user who is signing onto the database. You use the username to cross-reference with the TBL_USER_ID table columns USER_NAME and SECURITY_LEVEL to determine what the proper security level setting for the user should be. You then set a context variable called security_level to the correct security level for the user. You will use a database logon trigger to call the package. Listing 21.7 shows the creation of a context and then the creation of the context- checking package. Listing 21.7: Creating the Context and Context-Checking Package Grant the required privilege to create the context. CONNECT system/robert GRANT CREATE ANY CONTEXT TO spy_owner; GRANT DROP ANY CONTEXT TO spy_owner; GRANT CREATE ANY TRIGGER TO spy_owner; GRANT ADMINISTER DATABASE TRIGGER TO spy_owner; Now, connect and create the context. We will reference the currently nonexisting package pkg_spy_owner_context_01 as the context-checking package. We will write this package next. CONNECT spy_owner/spy_owner Drop any preexisting context. DROP CONTEXT spy_owner.cont_spy_owner_01; Create the context. Note that we could have used CREATE OR REPLACE instead. CREATE CONTEXT cont_spy_owner_01 USING spy_owner.pkg_spy_owner_context_01; Now, create the pkg_spy_owner_context_01 package header. CREATE OR REPLACE package spy_owner.pkg_spy_owner_context_01 AUTHID DEFINER AS PROCEDURE proc_get_spy_context(p_usern IN VARCHAR2); END; ENFORCING ROW-LEVEL SECURITY Beyond Simple Database Managment PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 21 • ORACLE8i DATABASE SECURITY 960 / Now, create the package body. CREATE OR REPLACE PACKAGE BODY pkg_spy_owner_context_01 AS PROCEDURE proc_get_spy_context(p_usern IN VARCHAR2) IS V_Spy_clearance NUMBER; BEGIN Now, take the p_usern, look it up in our tbl_userid table and get the correct clearance for this spy. SELECT security_level INTO v_spy_clearance FROM spy_owner.tbl_user_id WHERE user_name=p_usern; These next two lines will store the username and the user clearance level in the context for later use. SYS.DBMS_SESSION.SET_CONTEXT(’cont_spy_owner_01’,’v_spy_clearance’, v_spy_clearance); SYS.DBMS_SESSION.SET_CONTEXT(’cont_spy_owner_01’,’spy_id’,p_usern); END proc_get_spy_context; END pkg_spy_owner_context_01; / NOTE Notice the use of the DROP CONTEXT command in the example. This command will drop any existing context. To create a context, you must have the CREATE ANY CON- TEXT privilege. To drop a context requires the DROP ANY CONTEXT privilege. Keep in mind that setting the context, as done in Listing 21.7, and the actual implementation of FGAC are two different things. You are only setting the context area with the username and the clearance code because it will make the performance of your security policy (which truly implements FGAC) better. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 961 Executing the Context Package at User Logon Once the context-checking package is in place, you need to create a database logon event trigger to call the application context package. It is the job of this trigger to fire when the user logs in to the database. The user’s context area will be created, and then the application context package will be executed, determining the security level of the user. To create this logon trigger, you use the built-in SQL function SYS_CONTEXT. This function returns the value of a specific context variable to the calling program or SQL statement. Oracle provides a built-in context namespace for each user session called USERENV. You will use this built-in context namespace to get the username of the user who is logging in to the database. You will then pass that username to the appli- cation context-checking package. You will use the values stored in the context areas shortly. Listing 21.8 shows the logon trigger. Listing 21.8: Setting the Application Context with a Logon Trigger CONNECT spy_owner/spy_owner The logon trigger CREATE OR REPLACE TRIGGER tr_db_logon_01 AFTER LOGON ON DATABASE DECLARE spy_id VARCHAR2(30); BEGIN spy_id:=sys_context(’USERENV’,’SESSION_USER’); pkg_spy_owner_context_01.proc_get_spy_context(spy_id); EXCEPTION WHEN others THEN NULL; END; / Creating the Security Enforcement Package The next step is to create the security enforcement package. The security enforcement package will be executed when a user attempts to access the table that the security enforcement package will be assigned to in the next step. To enforce the row-level security, the security enforcement package adds a dynamic predicate to the SQL state- ment that is being executed. The dynamic predicate becomes an additional restriction to be appended to the SQL statement to be executed (basically, extending the WHERE clause to include restrictions for the implementation of row security). ENFORCING ROW-LEVEL SECURITY Beyond Simple Database Managment PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 21 • ORACLE8i DATABASE SECURITY 962 You can actually take advantage of FGAC by just writing this policy package and taking the next step, which is to register the package with the database. You don’t need to use contexts to use FGAC. In this example, you will append a predicate that basically says something to this effect: WHERE users_security_level>=tbl_secured_information.min_security_id Thus, if the user’s security level is greater than the minimum required security level in the TBL_SECURED_INFORMATION table, the user will be able to perform a given operation on that table (such as UPDATE or SELECT). The security enforcement pack- age (called PKG_TBL_SECURED_INFO_01 in this example) will construct this predi- cate and return it as a VARCHAR2 datatype to the database, where it will be applied to the SQL statement. Listing 21.9 provides an example of the creation of the security enforcement package. NOTE The additional predicate does not appear in data dictionary views of the SQL statement, such as V$SQL. Listing 21.9: Creating the Security Enforcement Package CONNECT spy_owner/spy_owner CREATE OR REPLACE PACKAGE pkg_spy_auth AUTHID DEFINER AS FUNCTION fu_spy_check(p_schema VARCHAR2, p_name VARCHAR2) RETURN VARCHAR2; END; / CREATE OR REPLACE PACKAGE body pkg_spy_auth AS FUNCTION fu_spy_check(p_schema VARCHAR2, p_name VARCHAR2) RETURN VARCHAR2 AS V_predicate VARCHAR2(2000); V_clearance NUMBER; BEGIN V_clearance:=sys_context(’cont_spy_owner_01’,’v_spy_clearance’); IF v_clearance IS NOT NULL THEN C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 963 V_predicate:= ’ min_security_id <= ’||v_clearance; ELSE V_predicate:= ’ 1 = 2’; END IF; RETURN v_predicate; END fu_spy_check; END pkg_spy_auth; / This package retrieves from the cont_spy_owner_01 context the clearance level of the person logged in to the database. It then checks to see if v_clearance is NULL, which will be the case if the user signs in as someone who is not in the security clear- ance table (TBL_USER_ID). If the user’s security clearance is set to NULL, the package creates a predicate that makes the SQL statement return no rows. Since the clause 1 = 2 is always going to evaluate as FALSE, this guarantees that you prevent access to the table to unauthorized users. Always include this clause to make sure your data is secured. If the clearance is not NULL, the package creates a predicate that indicates that the column MIN_SECURITY_ID should be less than or equal to the clearance level assigned. Once this procedure is associated with the TBL_SECURED_INFORMATION table, all queries will have this predicate attached to the end of them, thus enforcing the security. NOTE Some functions, such as DBMS_OUTPUT, will not execute in FGAC security enforcement packages. The package will compile but no output will be forthcoming. Also, autonomous transactions will cause a row-level security package to fail when executed. This is likely seen as a circumvention of security by Oracle. The UTL_FILE package, strangely enough, appears to work fine. Registering the Security Enforcement Package Now that you have written the security enforcement package, the final step is to enforce the rules represented by this package and relate that package to a table. The security enforcement package is related to the table through the use of the DBMS_RLS package. NOTE Oracle does not allow any security policies to apply to the SYS schema. ENFORCING ROW-LEVEL SECURITY Beyond Simple Database Managment PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 21 • ORACLE8i DATABASE SECURITY 964 The DBMS_RLS package is used to register your security enforcement package with the table that you wish that package to administer, as well as to manage the security enforcement packages. This package includes the DBMS_RLS.ADD_POLICY, DBMS_ RLS.DROP_POLICY, DBMS_RLS.ENABLE_POLICY, and DBMS_RLS.REFRESH_POLICY procedures. In this example, you use the DBMS_RLS.ADD_POLICY procedure to regis- ter the security enforcement package. Let’s take a quick look at that procedure: PROCEDURE dbms_rls.add_policy Argument Name Type In/Out Default? OBJECT_SCHEMA VARCHAR2 IN DEFAULT OBJECT_NAME VARCHAR2 IN POLICY_NAME VARCHAR2 IN FUNCTION_SCHEM VARCHAR2 IN DEFAULT POLICY_FUNCTION VARCHAR2 IN STATEMENT_TYPES VARCHAR2 IN DEFAULT UPDATE_CHECK BOOLEAN IN DEFAULT ENABLE BOOLEAN IN DEFAULT Listing 21.10 shows how to use this procedure to register the security enforcement package created with the database so it will execute on any DML statement that is executed on the table TBL_SECURED_INFORMATION. Listing 21.10: Adding the Policy with the DBMS_RLS.ADD_POLICY Procedure CONNECT SYS/yourpassword BEGIN Dbms_rls.add_policy(’SPY_OWNER’,’TBL_SECURED_INFORMATION’, ’SPY_OWNER’,’SPY_OWNER’, ’PKG_SPY_AUTH.FU_SPY_CHECK’, ’SELECT, INSERT, UPDATE, DELETE’, TRUE, TRUE); END; / As you can see, the DBMS_RLS.ADD_POLICY procedure takes several parameters. Table 21.5 describes each parameter. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 965 TABLE 21.5: PARAMETERS FOR THE DBMS_RLS.ADD_POLICY PROCEDURE Argument Default Value Description Object_schema NULL The schema that contains the table or view that you wish to register the policy for. If NULL, the current user schema will be used. Object_name None The name of the table or view that the policy is being added to. Policy_name None The name of the policy being assigned to the table or view. This name must be unique for each object. Function_schema NULL The name of the schema that owns the policy func- tion that is to be used. If NULL, the current user that you are logged in as will be used. Policy_function None The name of the function/package that is used to create the dynamic predicate (this is the security enforcement package). Statement_types All The statement types that the policy should apply to (SELECT, INSERT, UPDATE, DELETE). Update_check FALSE Causes the value to be checked again after an UPDATE or INSERT statement completes. Enable TRUE Enables the policy. The policy can be selectively enabled or disabled with the DBMS_RLS.ENABLE procedure. NOTE When you begin planning your security with FGAC, you may end up crafting mul- tiple policies for the same table. Oracle supports this type of approach, allowing you to register multiple policies for the same table. The other procedures in the DBMS_RLS package allow you to manage your poli- cies. You can drop policies with the DROP_POLICY procedure, enable or disable poli- cies with the ENABLE_POLICY procedure, and use the REFRESH_POLICY procedure to cause all SQL statements associated with the policy to be re-parsed. Testing the Security Enforcement Package So, you’ve written code, set up logon triggers, created the security enforcement pack- age, and added it as a security policy. You’re ready to go! Listing 21.11 provides the ENFORCING ROW-LEVEL SECURITY Beyond Simple Database Managment PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 21 • ORACLE8i DATABASE SECURITY 966 test. In this test, you log on to the database as each user and try to SELECT from the table. Let’s see what happens. Listing 21.11: Looking for a Security Breach SQL> CONNECT spy_owner/spy_owner Connected. SQL> SELECT * FROM tbl_secured_information; MIN_SECURITY_ID SECRET_INFORMATION 0 This is boring public information 10 Men are NOT from Mars!! 20 But the Aliens are from Mars!! 100 And they are here to take over the world. SQL> CONNECT public_access/public_access Connected. SQL> / no rows selected SQL> CONNECT secret_spy/secret_spy Connected. SQL> / MIN_SECURITY_ID SECRET_INFORMATION 0 This is boring public information 10 Men are NOT from Mars!! SQL> CONNECT top_secret_spy/top_secret_spy Connected. SQL> / MIN_SECURITY_ID SECRET_INFORMATION 0 This is boring public information 10 Men are NOT from Mars!! 20 But the Aliens are from Mars!! SQL> CONNECT license_to_kill/license_to_kill C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 967 Connected. SQL> / MIN_SECURITY_ID SECRET_INFORMATION 0 This is boring public information 10 Men are NOT from Mars!! 20 But the Aliens are from Mars!! 100 And they are here to take over the world. The Good, the Bad, and the Ugly about FGAC As is typical of any new feature, there are some good things and some bad things about using FGAC. The fact that FGAC works in the background, so that it is invisible to the user, is one of the advantages of using FGAC. And, of course, there is the bene- fit of making your database more secure. The main negative aspect to FGAC is the complexity involved in implementing the feature. However, once you have done it a couple of times, it becomes easier. Another issue with FGAC is the fact that it has the potential to negatively impact performance. Since the predicate to be added changes the SQL statement, you can end up with an execution plan that is different from what you expected. Since you have almost no way of knowing what predicate is being attached to the SQL state- ment, it makes tuning that SQL statement much more difficult. The complete SQL statement, with the predicate, doesn’t show up in the V$SQL view, and the predicate doesn’t appear if you enable Autotrace. If you look in a trace file, you will not see a predicate associated with your session. Predicates can impact performance. Depending on the predicate to be added, you could end up with more table joins than you expected, quickly turning a simple two table join into a three- or four-table join (or more). As a developer, DBA, or database architect, you need to consider the impacts of predicates and make sure that indexes are created to assist the database in properly handling the addition of the predicates. There is one way to determine what predicate is being added when you are run- ning SQL statements: Add event 10730. Setting this event will provide you with a trace file that contains the complete SQL statement you issued. This SQL statement will also include the dynamic FGAC predicate attached. If you are using Oracle ver- sion 8.1.5, your output will look somewhat different in that only the predicate will appear. In Oracle version 8.1.6 and later, you will find that the entire SQL statement appears, as shown here: ALTER SESSION SET EVENTS= ‘10730 trace name context forever, level 10’; ENFORCING ROW-LEVEL SECURITY Beyond Simple Database Managment PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... (BADFILE and DISCARDFILE), and the log file You’ll read about the various methods of loading data, and how to execute SQL*Loader from the command line or using a script NOTE The case studies in the Oracle documentation are good examples that will help you understand how to use SQL*Loader Introduction to SQL*Loader SQL*Loader will bring data in from a source external to Oracle and place that data into Oracle... can load data into the Oracle table faster, the direct path method has more restrictions Conventional path is what is used most often For more information about all three load methods, consult Oracle’s documentation on SQL*Loader Conventional Path Load Conventional path load is the default load type and will be used if you do not specify a load method You can use any of the record formats with this method... VARRAY • When table constraints are present Direct Path Load Restrictions on Direct Path Load The direct path load has several restrictions, including the following (For a complete list, consult the Oracle documentation.) • SQL strings are not allowed in the control file • The table into which you are loading data cannot contain LOB or VARRAY column types Please purchase PDF Split-Merge on www.verypdf.com... \control=1461c1.ctl log=servtype.log data=servtype.csv \bad=servtype.bad discard=servtyp.dis parallel=true \errors=10000 rows=1000 bindsize=100000000 Oracle has supplied a collection of case studies in the SQL*Loader documentation that may be of use to you in constructing your control files OPTIONS Clause The OPTIONS section contains the SQLLOAD command-line options You can specify these options within the control... REPLACE, or TRUNCATE) INTO TABLE is possibly the most complex clause of SQL*Loader’s control file NOTE For an in-depth breakdown of this control file section, you can go to Chapters 3 through 6 of the Oracle documentation on SQL*Loader If you specify INTO TABLE with one of the options INSERT, APPEND, REPLACE, or TRUNCATE, as described earlier, that option will take precedence over the INSERT, APPEND, REPLACE,... errors allowed and actual errors encountered • Makeup of the control file • When the load started and ended For more thorough coverage of the elements of SQL*Loader’s log files, consult the SQL*Loader documentation Listing 22.10: Example of SQL*Loader Log File Control File: Datafile: Bad File: /pac146/ctl/1463c.ctl /pac146/data/m1prj_midmo.txt /pac146/data/m1prj_midmo.bad Discard File: /pac146/data/m1prj_midmo.dis . from the command line or using a script. NOTE The case studies in the Oracle documentation are good examples that will help you understand how to use SQL*Loader. Introduction. often. For more information about all three load methods, consult Oracle’s documenta- tion on SQL*Loader. Conventional Path Load Conventional path load