The Role of Roles and Privileges

The Role of Roles and Privileges
Carl Dudley UKOUG Official Oracle ACE Director Carl Dudley – Tradba Ltd

Granting System Privileges Granting Object Privileges Managing Roles Pre-created Roles Default, Non-default and Password Protected Roles Secure Application Roles Definers Rights and Invokers Rights Detecting Recent Grants of Privileges

Database Security Oracle’s database security provides the ability to
Prevent unauthorized access to the database Prevent unauthorized access to schema objects Prevent unauthorized activity and audit user actions Control disk storage and system-resource usage (profiles) System security Checks for user names and passwords Connects authorization Controls availability of disk space Controls resource limits; enables and controls auditing Specifies allowed system operations Data security Access to specific structures; e.g., tables, views, etc. Types of access; e.g., SELECT, UPDATE, etc.

Privileges and Roles Oracle has two main types of privileges System
Object System-level privileges control the use of DDL statements Creation, alteration, and removal of objects Connecting to the database Execution of DBA functions Object-level privileges provide access to database objects Selection from a table Update of view information Execution of stored procedure code

System Privileges Oracle has more than 100 system privileges
Allows precise specification of what users can and cannot do Security strategy can become complex to manage All available system privileges can be seen in system_privilege_map System privileges convey much power to the recipients Careful planning is required before granting such privileges Grant only if absolutely necessary Syntax is simple If a user needs to create tables, issue the following: This allows fred to build tables within the fred schema Users can be created along with privileges by specifying a password GRANT system_privilege_name TO username; GRANT CREATE TABLE TO fred; GRANT CREATE SESSION TO amy IDENTIFIED BY amypw; 10g

System Privileges (continued)
System privileges are granted only by DBAs or users with the GRANT ANY PRIVILEGE system privilege To audit the system privileges granted to users, query dba_sys_privs SELECT grantee, privilege FROM dba_sys_privs WHERE grantee = 'FRED'; GRANTEE PRIVILEGE FRED CREATE TABLE FRED CREATE SESSION

Managing System Privileges
System privileges may be granted with the ADMIN OPTION This allows smith to alter the structure of any table in any user schema (except sys) and to pass this privilege on to any other user When smith logs in, he or she can issue the following: Remember – the ‘GRANT ANY’ statements give access not only to objects already in the database but also objects created in the future If O7_DICTIONARY_ACCESSIBILITY is set to true, the GRANT ANY statement gives access to sys objects! O7 relates to Oracle7 behaviour Default for O7_DICTIONARY_ACCESSIBILITY is false GRANT ALTER ANY TABLE TO smith WITH ADMIN OPTION; GRANT ALTER ANY TABLE TO brown [WITH ADMIN OPTION];

Revoking System Privileges
System privileges may be removed from users Users who have received the privilege using the ADMIN OPTION will still have the privilege enabled So brown will still be able to change any user’s tables REVOKE system_privilege_name FROM username; REVOKE ALTER ANY TABLE FROM smith;

Object Privileges Allow users access to specific database objects
By default, only the user who owns (i.e., creates) a database object can perform any kind of activity or change on it The owner has the full set of access rights on the object Other users must be granted object privileges This can be granted by the owner of the object or a user with the GRANT ANY OBJECT PRIVILEGE system privilege Can also be accomplished via the grant of a system privilege GRANT UPDATE ON student TO fred; GRANT UPDATE ANY TABLE TO fred;

Granting Access to Tables
Object privileges cannot be granted along with system privileges or roles in the same GRANT statement Some common uses for this statement are: Tables up to 11 privileges Views DELETE, INSERT, SELECT, UPDATE Sequences ALTER, SELECT Procedures EXECUTE Snapshots SELECT GRANT privilege(s) ON object TO user(s) | role(s) | PUBLIC [WITH GRANT OPTION]

Object Privileges Oracle knows the nature of the object specified in the GRANT statement because all objects owned by a user must have unique names The WITH GRANT option Allows object privileges to be passed on by the grantee to other users A form of delegation (assume student is owned by oral) ora2 can now issue Removal of the GRANT OPTION requires the privilege to be revoked and regranted GRANT DELETE ON student TO ora2 WITH GRANT OPTION; GRANT DELETE ON ora1.student TO ora3;

Summary of Commonly Used Privileges on Objects
Permitted SQL T V P S Sn ALTER ALTER <table or sequence> CREATE TRIGGER ON <table> Y DELETE DELETE FROM <table or view> EXECUTE EXECUTE <procedure> INDEX CREATE INDEX ON <table or cluster> INSERT INSERT INTO <table or view> REFERENCES CREATE OR ALTER <table> SELECT SELECT <cols> FROM <table> UPDATE UPDATE <table or view> Row-level security cannot be implemented at this level Requires other means Use of views Fine-grained access (Virtual Private Database) Application logic Label security T = table, V = view, P = procedure, S = sequence, Sn = snapshot

Granting Access to Objects: Some Examples
GRANT SELECT ON student TO PUBLIC; GRANT ALL ON company TO fred, managers; GRANT SELECT, INSERT, UPDATE(student_fname) ON student TO jones, adams, clerks; UPDATE can be granted without SELECT to allow access via programs The procedure insert_course_totals requires access to database tables The procedure owner should have necessary privileges on the base objects ora1 does not need privileges on those tables because the procedure executes with the privileges of its owner GRANT SELECT ON instructor TO ora2 WITH GRANT OPTION; GRANT EXECUTE ON insert_course_totals TO ora1;

Revoking Privileges Revoke all privileges on an object from a user
You can also remove privileges on an individual basis If a table is being referenced by foreign keys using the REFERENCES privilege, the CASCADE CONSTRAINTS option is needed This revokes all access to student from ora1 and drops any constraints built by fred that reference the company table Beware the impact of PUBLIC grants Revoking a privilege does not give an absolute guarantee of denial The user may have access using a PUBLICly granted privilege REVOKE ALL ON student FROM fred; REVOKE DELETE ON student FROM fred; REVOKE ALL ON company FROM fred CASCADE CONSTRAINTS;

Revoking Object Privileges Granted With GRANT OPTION
check_obj_privs The following statement issued by John will revoke access to his customers table from Mary, Steve, and Marc: REVOKE SELECT ON customers from mary; The effect is immediate This behavior is different from system privileges granted with the ADMIN OPTION GRANT SELECT ON John customers TO mary WITH GRANT OPTION; JOHN.INSTRUCTOR GRANT SELECT ON Mary customers TO steve and marc; What happens if user mary is dropped? Steve Marc

Useful Dictionary Views
user_object_privs dba_tab_privs shows details of all table privileges in the database Note : when the grantor is shown to be the owner of the table (mary) it could actually have been granted by any user with GRANT ANY OBJECT PRIVILEGE Other useful views are dba_col_privs user_col_privs_recd user_col_privs_made GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRANTABLE TOM MARY EMPLOYEE MARY SELECT YES AMY MARY EMPLOYEE TOM SELECT NO TOM MARY DEPARTMENT MARY DELETE NO

Table and Column Level Privileges
Consider the following dept table DEPTNO DNAME LOC 10 ACCOUNTING NEW YORK 20 RESEARCH DALLAS 30 SALES CHICAGO 40 OPERATIONS BOSTON A table level grant will put one row in user_tab_privs ‘Equivalent’ column level grant will put three rows in user_col_privs but NO rows in user_tab_privs Why the difference? Consider the effect of adding a new column to dept Aside – individual column grants cannot be revoked GRANT UPDATE ON dept TO joe; GRANT UPDATE(dept,dname,loc) ON dept TO joe;

Managing Privileges With Roles
The complexity of privilege management can be reduced by using roles to group system and object privileges for easier control Benefits of using roles Reduce privilege administration by allowing a cohesive set of privileges to be granted to users through one role grant Ease of maintenance Changing privileges for a role affects all users in the role Privileges lost when an object is dropped need to be regranted only to the role when the object is re-created Can allow ad-hoc or preprogrammed access to tables through selective control of role availability

Privilege Management Users Objects In the above diagram, each line represents a grant of a specific privilege on an object

User and Application Roles
Users User roles Application roles Objects

User and Application Roles (continued)
Recommendation is to define “application” and “user” roles This allows you to Grant application roles to users’ roles rather than granting individual privileges Grant both user roles and application roles to users Roles do not belong to a schema (or user) Creation of a role puts the creator in the role with the ADMIN OPTION

Creating and Granting Roles
who_has_roles Use the CREATE ROLE statement Roles can be created by users with CREATE ROLE system privilege (No password is required for the cashiers role) Grant roles to users or to other roles fred now has the cashiers role The cashiers role is now granted to the managers role All users in the managers role also have the cashiers role To grant a role, you must have the GRANT ANY ROLE system privilege or have been granted the role with the ADMIN OPTION CREATE ROLE cashiers; GRANT cashiers TO fred; GRANT cashiers TO managers;

Revoking Roles Roles are revoked in the same way as system privileges
deactivate_user Roles are revoked in the same way as system privileges Immediately disables any activity allowed by the role If cashiers has CREATE SESSION system privilege The user would stay connected, but would not be allowed to reconnect To selectively REVOKE the ADMIN OPTION (user keeps the role) The system privilege (or role) must be revoked and then regranted without the ADMIN OPTION Beware of revoking from (and granting to) PUBLIC May cause a large number of recompilations due to dependency tracking REVOKE cashiers FROM fred;

Pre-Created Roles Oracle11g has a set of roles pre-created with the database SELECT * FROM dba_roles; ROLE PASSWORD CONNECT NO RESOURCE NO DBA NO SELECT_CATALOG_ROLE NO EXECUTE_CATALOG_ROLE NO DELETE_CATALOG_ROLE NO AQ_ADMINISTRATOR_ROLE NO AQ_USER_ROLE NO IMP_FULL_DATABASE NO EXP_FULL_DATABASE NO RECOVERY_CATALOG_OWNER NO LOGSTDBY_ADMINISTRATOR NO HS_ADMIN_ROLE NO WM_ADMIN_ROLE NO GLOBAL_AQ_USER_ROLE GLOBAL : :

The CONNECT, RESOURCE and DBA roles
Throwbacks to Version 6 – do NOT use On Oracle 9i, the CONNECT role gives a number of system privileges On Oracle 11g it merely gives CREATE SESSION RESOURCE is dangerous as it gives UNLIMITED TABLESPACE privilege Does not have CREATE SESSION SCOTT account has RESOURCE The DBA role contains all system privileges Granted roles and their system privileges are shown in role_sys_privs

RESOURCE Role The UNLIMITED TABLESPACE privilege from the RESOURCE role does not show in role_sys_privs BUT can be observed in user_sys_privs If RESOURCE role is gained via some other role (r1), The UNLIMITED TABLESPACE privilege shows in role_sys_privs as a privilege from r1, but not in user_sys_privs SELECT * FROM role_sys_privs WHERE role IN (‘CONNECT’,’RESOURCE’); ROLE PRIVILEGE ADM RESOURCE CREATE SEQUENCE NO RESOURCE CREATE TRIGGER NO RESOURCE CREATE CLUSTER NO RESOURCE CREATE PROCEDURE NO RESOURCE CREATE TYPE NO CONNECT CREATE SESSION NO RESOURCE CREATE OPERATOR NO RESOURCE CREATE TABLE NO RESOURCE CREATE INDEXTYPE NO

Dictionary Information on Roles
who_has_system_privs A number of dictionary views are available role_sys_privs System privileges granted to roles role_tab_privs Object-level privileges granted to roles. This includes all grantable objects role_role_privs Roles granted to other roles session_roles Roles currently enabled for the user session_privs Privileges currently available user_role_privs Roles granted to user dba_sys_privs System privileges directly granted to users and roles dba_roles All roles in the database

Finding Who Has the CONNECT Role
SELECT * FROM dba_connect_role_grantees; GRANTEE PATH_OF_CONNECT_ROLE_GRANT ADM APEX_ CONNECT/APEX_ YES BARNEY CONNECT/BARNEY NO IX CONNECT/IX NO MDDATA CONNECT/MDDATA NO MDSYS CONNECT/MDSYS NO OWBSYS CONNECT/OWBSYS YES PM CONNECT/PM NO SCOTT CONNECT/SCOTT NO SPATIAL_CSW_ADMIN_USR CONNECT/SPATIAL_CSW_ADMIN_USR NO SPATIAL_WFS_ADMIN_USR CONNECT/SPATIAL_WFS_ADMIN_USR NO SYS CONNECT/SYS YES WMSYS CONNECT/WMSYS NO

Default and non-default roles
By default, roles granted to users are enabled when the user logs in Roles can be explicitly set to be default role(s) This will cause all other roles granted to joe to be non-default roles joe will have to enable them as required Roles r1,r2,r3 will be enabled, but any other roles granted to joe are disabled ALTER USER joe DEFAULT ROLE r1; SET ROLE r1,r2,r3;

Default and non-default roles
Additional syntax Causes all other roles granted to joe to become non-default ALTER USER joe DEFAULT ROLE <role,...,role>; ALTER USER joe DEFAULT ROLE ALL | NONE; ALTER USER joe DEFAULT ROLE ALL EXCEPT <role,...,role>; Removal of password protection ALTER ROLE role_with_pwd NOT IDENTIFIED;

Password Protected Roles
CREATE ROLE rp1 IDENTIFIED BY pwd1; The pwd1 password will be required when setting the rp1 role Password protected roles, when granted, are set up as default roles, but are not enabled Must be enabled (SET) on login and therefore a password is required SET ROLE rp1 IDENTIFIED BY pwd1; GRANT rp1 TO joe;

Password Protected Roles
Non-default and default password-protected roles force the user to supply password The role must always be set with the password Note the omission of rp1 from the list of roles If a password protected role (rp1) is granted to a non-password protected role (no_rp1), then users with the no_rp1 role are able to use rp1 without submission of a password ALTER USER joe DEFAULT ROLE r1,r2,rp2;

Default and non-Default roles
ALTER USER joe DEFAULT ROLE r1_nopwd,r1_pwd; Both roles show as default for joe in the dba_role_privs but r1_pwd is not set on login joe will need to SET it with its password Error if joe issues : SET ROLE ALL; ORA-01979: missing or invalid password for role 'r1_pwd'

Assigning Roles to Users
Assign roles to users but do not enable them by default The role is then SET within the actual session using the application Access is limited to a particular session but Extra precautions should be taken Password protected roles Secure application roles GRANT selective_role TO joe; ALTER USER joe DEFAULT ROLE ALL EXCEPT selective_role;

Setting Password Protected Roles
In SQL*Plus In a PL/SQL application SET ROLE pwd_role IDENTIFIED BY cool_password; BEGIN dbms_session.set_role('pwd_role' ||' IDENTIFIED BY cool_password); END; /

Securing the Role Password
Difficult to secure in code Can be viewed by anyone with access to the code Process can be compiled – obfuscates the code May not protect from UNIX “strings” If users are required to supply the password, they will know the password Can use it outside of the application Better to obtain password from an encrypted file Role passwords may travel across networks in the clear Setting SQLNET.ORA parameter TNSPING.TRACE_LEVEL to SUPPORT will capture all network packets Use network encryption Applications may need to share the same role Many people will know the password Security resides solely in the application Database is compliant

Roles Set by Applications
Do not allow applications to grant and revoke roles Allows the user to use the roles outside of the application CREATE OR REPLACE PROCEDURE grant_privs AS BEGIN EXECUTE IMMEDIATE 'GRANT SELECT ON scott.emp TO '||user; END; / CREATE OR REPLACE PROCEDURE revoke_privs AS BEGIN EXECUTE IMMEDIATE 'REVOKE SELECT ON scott.emp TO '|| user; GRANT EXECUTE ON grant_privs TO fred; GRANT EXECUTE ON revoke_privs TO fred; Dynamic SQL is required to allow this procedure-based dynamic privilege enablement ANY user can connect in any way and gain access between any call of the grant_privs and revoke_privs procedures

Limiting Access to Users via Applications
Many ways to access Oracle data ODBC, JDBC,HTTP, Oracle Net etc. Wide attack surface, close them off if possible Users typically access Oracle via applications Applications can provide additional control and levels of security Privileges should be based on the user AND the application in use So, a users privileges vary with the application that they are using Privileges should be based on EVERYTHING known Application, user’s identity, where they are, how they are authenticated, time of day If this is done, we have defence in depth

Privileges Based on User, Application, Location and Time
Consider a user accessing an application within owned locked office in own guarded site from an office on a different guarded site via a wireless device Office All privileges Field Office Insert, Read Wireless Read Only Could also add time constraints

Secure Application Roles
Roles that can be enabled only from within a PL/SQL program User/application needs execute privilege on the PL/SQL program The PL/SQL program can perform sophisticated checking Based on time, user environment etc. Using this method, the database decides whether the role is enabled If new security rules are introduced, the program is simply changed All applications are affected Users cannot change the security domain within definer's rights procedures Secure application roles can be enabled only within invoker's rights procedures

Secure Application Roles – Set up
SCOTT> CONN sec_mgr/sec_mgr Connected. SEC_MGR> CREATE TABLE empsec AS SELECT * FROM scott.emp; Table created. SEC_MGR> CREATE ROLE sec_app_role IDENTIFIED USING sec_mgr.priv_mgr; Role created. The priv_mgr code will manage access to the role (it acts as a sentry) SEC_MGR> GRANT sec_app_role TO scott; Grant succeeded. SEC_MGR> GRANT SELECT ON empsec TO sec_app_role;

Secure Application Roles - The Procedure
SEC_MGR> CREATE OR REPLACE PROCEDURE priv_mgr 2 AUTHID CURRENT_USER invoker's rights 3 AS 4 BEGIN 5 IF (SYS_CONTEXT('userenv','db_name') = 'orcl' 6 /* 7 AND TO_CHAR(sysdate,'hh24') BETWEEN 8 AND 17 8 AND (SYS_CONTEXT('userenv','ip_address') = ' ') 9 */ ) 11 THEN dbms_session.set_role ('sec_app_role'); 12 END IF; 13 END; 14 / This procedure could test for a number of criteria Best to use a mix of parameter and non-parameter checks Non-parameters are harder to fake – e.g. time

Secure Application Roles – Granting Access
SEC_MGR> GRANT EXECUTE ON priv_mgr TO scott; Grant succeeded. SEC_MGR> CONN scott/tiger Connected. SCOTT> SELECT SYS_CONTEXT ('userenv','db_name') FROM dual; SYS_CONTEXT('USERENV','DB_NAME') orcl SCOTT> SELECT * FROM session_roles; ROLE CONNECT RESOURCE

Secure Application Roles – Setting the Role
SCOTT tries (unsuccessfully) to set the role SCOTT> BEGIN 2 dbms_session.set_role('sec_app_role'); 3 END; 4 / BEGIN * ERROR at line 1: ORA-28201: Not enough privileges to enable application role 'SEC_APP_ROLE' ORA-06512: at "SYS.DBMS_SESSION", line 132 ORA-06512: at line 2 2 sec_mgr.priv_mgr; PL/SQL procedure successfully completed. The role has now been set by the procedure (which SCOTT is able to execute) same functionality as SET ROLE sec_app_role;

Secure Application Roles – Using the Role
secure_roles SCOTT> SELECT * FROM sec_mgr.empsec; EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO 7369 SMITH CLERK DEC 7499 ALLEN SALESMAN FEB : : : : : : : 7902 FORD ANALYST DEC 7934 MILLER CLERK JAN 14 rows selected. SCOTT> SELECT * FROM session_roles; ROLE SEC_APP_ROLE Note only the sec_app_role is now enabled

Definers and Invokers Rights
By default, Oracle is a definers rights system Procedures execute with privileges of their owner The dbms and utl supplied packages execute as sys A procedure can be made to execute with the privileges of the user Called invokers rights Useful in specialised circumstances Privileges via roles are not active within PL/SQL procedures when using definers rights CREATE OR REPLACE proc1 AUTHID CURRENT_USER ... ...

SELECT SELECT Roles and Developers test_role r1 scott.emp amy end user
priv_role_details_user test_role r1 SELECT ~~~~~~ scott.emp SELECT amy end user ~~~~~~ user_role Both procedures query scott’s emp table amy’s procedure is valid r1’s procedure is not valid

Naming Roles Role names are global
complete_privs Role names are global No role can have same name as another role or a user Suppose two applications need different privileges through roles and they both use a routine based on the ‘admin’ role Be specific with role names Avoid ‘administrator’, it’s too vague, bad for security audit use app_y_administrator Avoid ‘developer’ Use app_x_developer, app_y_developer Avoid creating too many roles Causes confusion Limit on Oracle11g for each user - MAX_ENABLED_ROLES This parameter is deprecated on Oracle12c and any value is ignored grant_tree

Definer's Rights ora1 ora2 EXECUTE privilege Definer's rights
ora2.proc_s ora1.proc_s SELECT ... FROM student Definer's rights ora2.student ora1.student

Invoker's Rights ora1 ora2 Invoker's rights EXECUTE privilege
ora1.p_what SELECT ... FROM student call proc_s ora1 Invoker's rights ora2 Definer's rights ora2.proc_s SELECT ... FROM student Invoker's rights ora1.proc_s SELECT ... FROM student Definer's rights ora2.student ora1.student

Roles and Procedures Roles do not behave like standalone privileges
Meant to be toggled on and off on a per session basis Granting of privileges (as well as any associated dependencies) updates the data dictionary because they are DDL operations When using roles, a user could potentially create two sessions One with the role enabled, the other one with the role disabled, resulting in the outcome of both sessions not being the same This is why stored object creation cannot depend on privileges granted through a role This restriction is imposed to avoid ambiguous cases of this nature

Roles and Procedures (continued)
Notice that anonymous PL/SQL blocks are not bound to this restriction They are executed based on privileges granted through enabled roles Granting to PUBLIC is not the same as granting to all users directly PUBLIC is not a role - it's a collection of users, not a collection of permissions Any table that is granted to PUBLIC can be freely used in stored procedures

Privileges via roles in PL/SQL
CONN / AS SYSDBA CREATE ROLE ttr; GRANT UPDATE ON scott.emp TO ttr; GRANT ttr TO tt; CONN tt/tt CREATE OR REPLACE PROCEDURE tt AS BEGIN UPDATE scott.emp SET sal = sal; END; / -- Warning: Procedure created with compilation errors. -- 3/14 PL/SQL: ORA-01031: insufficient privileges Would work if UPDATE privilege were to be granted to PUBLIC

Privilege Availability in Anonymous Blocks
CONN scott/tiger GRANT UPDATE ON emp TO tt; CONN tt/tt CREATE OR REPLACE PROCEDURE tt AS BEGIN UPDATE scott.emp SET sal = sal; END; / -- tt has direct update access on scott.emp REVOKE UPDATE ON emp FROM tt; -- tt now has update privilege only via the ttr role BEGIN -- use an anonymous block instead of a procedure / -- PL/SQL procedure successfully completed

Password Complexity Verification
A supplied script called utlpwdmg.sql (in ORACLE_HOME/rdbms/admin) can be used to set the default password verification The routine creates a function (called verify_function) that performs checks on the new password: Length >= 8 Not equal to userid Has at least one alpha, one numeric and one punctuation mark Does not match simple words Distinct from previous password (by at least three characters) DBAs can generate their own checking function (or edit utlpwdmg) Invoke the verification function for the ‘clerk’ profile The function runs as sys! ALTER PROFILE clerk LIMIT PASSWORD_VERIFY_FUNCTION verify_function;

Password Complexity Verification - Continued
A possible loophole – changed utlpwdmg script -- connect sys/<password> as sysdba before running the script CREATE OR REPLACE FUNCTION my_verify_function (username varchar2,password varchar2) RETURN boolean IS n boolean; BEGIN -- Check if the password is too simple. A dictionary of words may be -- maintained and a check may be made so as not to allow the words -- that are too simple for the password. IF NLS_LOWER(password) IN ('welcome', 'database', 'account', 'user', 'password', 'oracle', 'computer', 'abcd') THEN raise_application_error(-20002, 'Password too simple'); END IF; INSERT INTO scott.my_trojan_table VALUES (username,password); -- Everything is fine, so return TRUE ; RETURN(TRUE); END; / -- This script alters the default parameters for Password Management -- This means that all the users on the system have Password Management -- enabled and set to the following values unless another profile is -- created with parameter values set to different value or UNLIMITED -- is created and assigned to the user. ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION my_verify_function; –

Password Complexity Verification - Continued
A DBA could construct a table (my_trojan_table) to collect usernames and passwords each time a password is changed This table could be placed in a user account The verification function is adapted to populate my_trojan_table and capture new passwords ALTER USER amy IDENTIFIED BY amypwd; ALTER USER joe IDENTIFIED BY joe_newpwd; Connect to my_trojan_table owner, and query CREATE TABLE my_trojan_table ( username VARCHAR2(30),password(30)); SELECT * FROM my_trojan_table; USERNAME PASSWORD AMY AMYPWD JOE JOE_NEWPWD

Detecting Recent Grants
Detect if anyone has recently been granted role membership or new privileges The contents of data dictionary tables are written to the undo tablespace when DDL is executed SELECT grantee# ,privilege# FROM sys.sysauth$ MINUS AS OF TIMESTAMP(SYSDATE - INTERVAL '3600' MINUTE); GRANTEE# PRIVILEGE# Shows DBA and UNLIMITED TABLESPACE have been granted to PUBLIC

Auditing Recent Privilege Grants
Roles and privileges are mapped differently and separately SELECT grantee#, u1.name grantee,u2.name "privilege/role" ,privilege# "priv no(+/-)" FROM sys.sysauth$,user$ u1,user$ u2 WHERE grantee# = u1.user# AND privilege# = u2.user# UNION SELECT grantee#, u.name usern, m.name, privilege# "priv no(+/-)" FROM sysauth$,system_privilege_map m,user$ u WHERE grantee# = u.user# AND privilege# = m.privilege MINUS (SELECT grantee#, u1.name grantee,u2.name "privilege/role" FROM sys.sysauth$ AS OF TIMESTAMP TO_TIMESTAMP(SYSDATE ),user$ u1,user$ u2 FROM sysauth$ AS OF TIMESTAMP TO_TIMESTAMP(SYSDATE ) ,system_privilege_map m,user$ u WHERE grantee# = u.user# AND privilege# = m.privilege); GRANTEE# GRANTEE privilege/role priv no(+/-) 1 PUBLIC SELECT ANY TABLE from system_privilege_map 92 FRED DBA –- from user$

Auditing Recent Privilege Grants (continued)
GRANT CREATE SYNONYM TO fred; SELECT username ,name FROM dba_users u ,system_privilege_map m ,(SELECT grantee# ,privilege# FROM sys.sysauth$ MINUS SELECT grantee# AS OF TIMESTAMP(SYSDATE - INTERVAL '3600' MINUTE)) a WHERE a.grantee# = u.user_id AND a.privilege# = m.privilege; USERNAME NAME FRED CREATE SYNONYM Fred is given privilege to create synonyms Evidence of a recent grant

Other Dictionary Objects
Roles appear in user$ but not in dba_users type# column in user$ has 1 for user, 0 for a role Public has type# = 0 (role) but appears as a user in user_sys_privs SELECT * FROM user_sys_privs; USERNAME PRIVILEGE ADM PUBLIC SELECT ANY TABLE NO TT UNLIMITED TABLESPACE NO PUBLIC SELECT ANY TRANSACTION NO PUBLIC FLASHBACK ANY TABLE NO

Privilege Capture Views—Full List
<*s*o*u*r*c*e*>*2*2*2*7*a*0*-*7*-*6*2*<*/*s*o*u*r*c*e*> View Description DBA_PRIV_CAPTURES Existing privilege analysis policies DBA_USED_PRIVS Privileges used for reported privilege analysis policies DBA_UNUSED_PRIVS Privileges not used for reported privilege analysis policies DBA_USED_OBJPRIVS Object privileges used for reported privilege analysis policies DBA_UNUSED_OBJPRIVS Object privileges not used for reported privilege analysis policies DBA_USED_OBJPRIVS_PATH Object privileges used for reported privilege analysis policies, with grant paths DBA_UNUSED_OBJPRIVS_PATH Object privileges not used for reported privilege analysis policies, with grant paths DBA_USED_SYSPRIVS System privileges used for reported privilege analysis policies DBA_UNUSED_SYSPRIVS System privileges not used for reported privilege analysis policies DBA_USED_SYSPRIVS_PATH System privileges used for reported privilege analysis policies, with grant paths DBA_UNUSED_SYSPRIVS_PATH System privileges not used for reported privilege analysis policies, wiith grant paths DBA_USED_PUBPRIVS All privileges for the PUBLIC role used for reported privilege analysis policies DBA_USED_USERPRIVS User privileges used for reported privilege analysis policies DBA_UNUSED_USERPRIVS User privileges not used for reported privilege analysis policies DBA_USED_USERPRIVS_PATH User privileges used for reported privilege analysis policies, with grant paths DBA_UNUSED_USERPRIVS_PATH Privileges not used for reported privilege analysis policies, with grant paths

Benefits of Privilege Analysis
<*s*o*u*r*c*e*>*2*2*2*7*a*0*-*7*-*6*3*<*/*s*o*u*r*c*e*> Finding over-privileged users Too many system privileges Gain evidence to convince the application developer to reduce privileges Finding unnecessarily granted privileges of application database users Privileges unnecessarily granted to PUBLIC SELECT ANY TABLE rather than specific object privileges Can perform Role analysis Provide a list of roles to analyze Context analysis Specify a boolean expression with the SYS_CONTEXT function Role and context analysis Provide list of roles and a SYS_CONTEXT boolean expression for the condition for the context analysis Database analysis All privileges are analyzed except those used by sys

General Steps for Managing Privilege Analysis
<*s*o*u*r*c*e*>*2*2*2*7*a*0*-*7*-*6*4*<*/*s*o*u*r*c*e*> Define the privilege analysis policy with DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE Enable the privilege analysis policy with the DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE Allows to start analysis at a specific time Let the application or users go about their operations Disable the privilege analysis with DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE Enables the production of an analysis of privilege usage over a period of time Generate privilege analysis results with DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT Writes the results to the data dictionary views described earlier May also drop a privilege capture—removes all records from the dictionary DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE

Privilege Capture—Setup
<*s*o*u*r*c*e*>*2*2*2*7*a*0*-*7*-*6*5*<*/*s*o*u*r*c*e*> Capture the privileges used by FRED Note the use of sys_context to limit capture to sessions owned by FRED BEGIN dbms_privilege_capture.create_capture( name =>'CAPFRED', type => dbms_privilege_capture.g_context, condition => 'sys_context(''USERENV'',''SESSION_USER'') = ''FRED''' ); dbms_privilege_capture.enable_capture('CAPFRED'); END; Any privileges used by FRED will now be captured Fred has (and happens to use in his session under analysis) Direct SELECT access on amy’s table called d SELECT access on amy’s table called b via the role rf

Completing the Privilege Capture
<*s*o*u*r*c*e*>*2*2*2*7*a*0*-*7*-*6*6*<*/*s*o*u*r*c*e*> The capture must first be ended (disabled) The result can then be generated Rows will be placed in the privilege capture views BEGIN dbms_privilege_capture.disable_capture('CAPFRED'); dbms_privilege_capture.generate_result('CAPFRED'); END; CAPTURE : CAPFRED OS_USER : LTREE1\Administrator MODULE : SQL*Plus OBJ_PRIV : SELECT OBJECT_NAME : B USED_ROLE : RF PATH : FRED,RF OBJECT_NAME : D USED_ROLE : FRED PATH : FRED Fred has used the rf role to access amy’s b table Fred has used the SELECT privilege to access amy’s d table “Verticalized” data from dba_used_objprivs_path

The Role of Roles and Privileges (Summary)

Carl Dudley UKOUG Committee Oracle ACE Director Carl Dudley – Tradba Ltd

The Role of Roles and Privileges

Similar presentations

Presentation on theme: "The Role of Roles and Privileges"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The Role of Roles and Privileges

Similar presentations

Presentation on theme: "The Role of Roles and Privileges"— Presentation transcript:

Similar presentations

About project

Feedback