Transcript privilegesandroles_problem

The Role of Roles and Privileges
Carl Dudley
UKOUG Official
Oracle ACE Director
[email protected]
Carl Dudley – Tradba Ltd
1
The Role of Roles and Privileges
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
2
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.
3
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
4
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
GRANT system_privilege_name TO username;
 If a user needs to create tables, issue the following:
GRANT CREATE TABLE TO fred;
• This allows fred to build tables within the fred schema
 Users can be created along with privileges by specifying a password
GRANT CREATE SESSION TO amy IDENTIFIED BY amypw;
10g
5
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
------FRED
FRED
PRIVILEGE
------------------CREATE TABLE
CREATE SESSION
6
Managing System Privileges
 System privileges may be granted with the ADMIN OPTION
GRANT ALTER ANY TABLE TO smith WITH 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:
GRANT ALTER ANY TABLE TO brown [WITH ADMIN OPTION];
 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
7
Revoking System Privileges
 System privileges may be removed from users
REVOKE system_privilege_name FROM username;
REVOKE ALTER ANY TABLE FROM smith;
 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
8
The Role of Roles and Privileges
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
9
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
GRANT UPDATE ON student TO fred;
— 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 ANY TABLE TO fred;
10
Granting Access to Tables
GRANT privilege(s) ON object
TO user(s) | role(s) | PUBLIC
[WITH GRANT OPTION]
— Object privileges cannot be granted along with system privileges or roles in
the same GRANT statement
 Some common uses for this statement are:
Tables
Views
up to 11 privileges
DELETE, INSERT, SELECT, UPDATE
Sequences
ALTER, SELECT
Procedures
EXECUTE
Snapshots
SELECT
11
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)
GRANT DELETE ON student TO ora2 WITH GRANT OPTION;
• ora2 can now issue
GRANT DELETE ON ora1.student TO ora3;
— Removal of the GRANT OPTION requires the privilege to be revoked and
regranted
12
Summary of Commonly Used Privileges on Objects
Privilege
Permitted SQL
T
V
ALTER
ALTER <table or sequence>
CREATE TRIGGER ON <table>
Y
DELETE
DELETE FROM <table or view>
Y
EXECUTE
EXECUTE <procedure>
INDEX
CREATE INDEX ON <table or cluster>
Y
INSERT
INSERT INTO <table or view>
Y
REFERENCES
CREATE OR ALTER <table>
Y
SELECT
SELECT <cols> FROM <table>
Y
Y
UPDATE
UPDATE <table or view>
Y
Y
P
S
Sn
Y
Y
Y
Y
Y
Y
 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
13
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
GRANT SELECT ON instructor TO ora2 WITH GRANT OPTION;
GRANT EXECUTE ON insert_course_totals TO ora1;
 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
14
Revoking Privileges
 Revoke all privileges on an object from a user
REVOKE ALL ON student FROM fred;
— You can also remove privileges on an individual basis
REVOKE DELETE ON student FROM fred;
 If a table is being referenced by foreign keys using the REFERENCES
privilege, the CASCADE CONSTRAINTS option is needed
REVOKE ALL ON company FROM fred CASCADE CONSTRAINTS;
— 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
15
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
customers TO mary
WITH GRANT OPTION;
John
JOHN.INSTRUCTOR
GRANT SELECT ON
customers TO steve
and marc;
Mary
What happens if
user mary is dropped?
Steve
Marc
16
Useful Dictionary Views
user_object_privs
 dba_tab_privs shows details of all table privileges in the database
GRANTEE
------TOM
AMY
TOM
OWNER TABLE_NAME
----- ---------MARY EMPLOYEE
MARY EMPLOYEE
MARY DEPARTMENT
GRANTOR
------MARY
TOM
MARY
PRIVILEGE
---------SELECT
SELECT
DELETE
GRANTABLE
--------YES
NO
NO
— 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
17
Table and Column Level Privileges
 Consider the following dept table
DEPTNO
------10
20
30
40
DNAME
-------------ACCOUNTING
RESEARCH
SALES
OPERATIONS
LOC
------------NEW YORK
DALLAS
CHICAGO
BOSTON
 A table level grant will put one row in user_tab_privs
GRANT UPDATE ON dept TO joe;
 ‘Equivalent’ column level grant will put three rows in user_col_privs
but NO rows in user_tab_privs
GRANT UPDATE(dept,dname,loc) ON dept TO joe;
 Why the difference?
— Consider the effect of adding a new column to dept
 Aside – individual column grants cannot be revoked
18
The Role of Roles and Privileges
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
19
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
20
Privilege Management
Users
Objects
 In the above diagram, each line represents a grant of a specific privilege on
an object
21
User and Application Roles
Users
User roles
Application roles
Objects
22
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
23
Creating and Granting Roles
who_has_roles
 Use the CREATE ROLE statement
— Roles can be created by users with CREATE ROLE system privilege
CREATE ROLE cashiers;
(No password is required for the cashiers role)
 Grant roles to users or to other roles
GRANT cashiers TO fred;
— fred now has the cashiers role
GRANT cashiers TO managers;
— 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
24
Revoking Roles
deactivate_user
 Roles are revoked in the same way as system privileges
REVOKE cashiers FROM fred;
— 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
25
The Role of Roles and Privileges
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
26
Pre-Created Roles
 Oracle11g has a set of roles pre-created with the database
SELECT * FROM dba_roles;
ROLE
-------------------CONNECT
RESOURCE
DBA
SELECT_CATALOG_ROLE
EXECUTE_CATALOG_ROLE
DELETE_CATALOG_ROLE
AQ_ADMINISTRATOR_ROLE
AQ_USER_ROLE
IMP_FULL_DATABASE
EXP_FULL_DATABASE
RECOVERY_CATALOG_OWNER
LOGSTDBY_ADMINISTRATOR
HS_ADMIN_ROLE
WM_ADMIN_ROLE
GLOBAL_AQ_USER_ROLE
:
PASSWORD
----------------NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
GLOBAL
:
27
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
28
RESOURCE Role
 The UNLIMITED TABLESPACE privilege from the RESOURCE role does not
show in role_sys_privs
SELECT * FROM role_sys_privs
WHERE role IN (‘CONNECT’,’RESOURCE’);
ROLE
-------------RESOURCE
RESOURCE
RESOURCE
RESOURCE
RESOURCE
CONNECT
RESOURCE
RESOURCE
RESOURCE
PRIVILEGE
-----------------CREATE SEQUENCE
CREATE TRIGGER
CREATE CLUSTER
CREATE PROCEDURE
CREATE TYPE
CREATE SESSION
CREATE OPERATOR
CREATE TABLE
CREATE INDEXTYPE
ADM
--NO
NO
NO
NO
NO
NO
NO
NO
NO
— 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
29
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
30
Finding Who Has the CONNECT Role
SELECT * FROM dba_connect_role_grantees;
GRANTEE
---------------------APEX_030200
BARNEY
IX
MDDATA
MDSYS
OWBSYS
PM
SCOTT
SPATIAL_CSW_ADMIN_USR
SPATIAL_WFS_ADMIN_USR
SYS
WMSYS
PATH_OF_CONNECT_ROLE_GRANT
-----------------------------CONNECT/APEX_030200
CONNECT/BARNEY
CONNECT/IX
CONNECT/MDDATA
CONNECT/MDSYS
CONNECT/OWBSYS
CONNECT/PM
CONNECT/SCOTT
CONNECT/SPATIAL_CSW_ADMIN_USR
CONNECT/SPATIAL_WFS_ADMIN_USR
CONNECT/SYS
CONNECT/WMSYS
ADM
--YES
NO
NO
NO
NO
YES
NO
NO
NO
NO
YES
NO
31
The Role of Roles and Privileges
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
32
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)
ALTER USER joe DEFAULT ROLE r1;
— This will cause all other roles granted to joe to be non-default roles
• joe will have to enable them as required
SET ROLE r1,r2,r3;
• Roles r1,r2,r3 will be enabled, but any other roles granted to joe are
disabled
33
Default and non-default roles
 Additional syntax
ALTER USER joe DEFAULT ROLE <role,...,role>;
— Causes all other roles granted to joe to become non-default
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;
34
Password Protected Roles
CREATE ROLE rp1 IDENTIFIED BY pwd1;
— The pwd1 password will be required when setting the rp1 role
SET ROLE rp1 IDENTIFIED BY pwd1;
 Password protected roles, when granted, are set up as default roles, but are
not enabled
GRANT rp1 TO joe;
— Must be enabled (SET) on login and therefore a password is required
35
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
ALTER USER joe DEFAULT ROLE r1,r2,rp2;
• 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
36
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'
37
Assigning Roles to Users
 Assign roles to users but do not enable them by default
GRANT selective_role TO joe;
ALTER USER joe DEFAULT ROLE ALL EXCEPT selective_role;
— 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
38
Setting Password Protected Roles
 In SQL*Plus
SET ROLE pwd_role IDENTIFIED BY cool_password;
 In a PL/SQL application
BEGIN
dbms_session.set_role('pwd_role'
||' IDENTIFIED BY cool_password);
END;
/
39
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
40
The Role of Roles and Privileges
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
41
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;
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
42
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
43
Privileges 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
44
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
45
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;
Grant succeeded.
46
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') = '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
47
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
48
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 /
same functionality as
BEGIN
SET ROLE sec_app_role;
*
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
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)
49
Secure Application Roles – Using the Role
secure_roles
SCOTT> SELECT * FROM sec_mgr.empsec;
EMPNO
----7369
7499
:
7902
7934
ENAME
---------SMITH
ALLEN
:
FORD
MILLER
JOB
--------CLERK
SALESMAN
:
ANALYST
CLERK
MGR
---7902
7698
HIREDATE
--------17-DEC-80
20-FEB-81
:
7566 03-DEC-81
7782 23-JAN-82
SAL COMM DEPTNO
---- ---- -----800
20
1600 300
30
:
:
:
3000
20
1300
10
14 rows selected.
SCOTT> SELECT * FROM session_roles;
ROLE
-----------------------------SEC_APP_ROLE
• Note only the sec_app_role is now enabled
50
The Role of Roles and Privileges
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
51
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
CREATE
OR REPLACE
proc1
AUTHID CURRENT_USER ...
...
 Privileges via roles are not active within PL/SQL procedures when using
definers rights
52
Roles and Developers
priv_role_details_user
r1
test_role
~~~~~~
~~~~~~
~~~~~~
~~~~~~
~~~~~~
~~~~~~
~~~~~~
scott.emp
amy
end user
user_role
~~~~~~
~~~~~~
~~~~~~
~~~~~~
~~~~~~
~~~~~~
~~~~~~
 Both procedures query scott’s emp table
— amy’s procedure is valid
— r1’s procedure is not valid
53
Naming Roles
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
grant_tree
 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
54
Definer's Rights
ora1
ora2
Definer's rights
ora1.proc_s
ora2.proc_s
SELECT ...
FROM student
Definer's rights
ora1.student
ora2.student
55
Invoker's Rights
Invoker's rights
ora1.p_what
EXECUTE privilege
SELECT ...
FROM student
ora1
call proc_s
Definer's rights
ora1.proc_s
ora2
Invoker's
rights
SELECT ...
FROM student
ora2.proc_s
SELECT ...
FROM student
Definer's rights
ora1.student
ora2.student
56
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
57
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
58
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
59
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
CONN scott/tiger
REVOKE UPDATE ON emp FROM tt;
-- tt now has update privilege only via the ttr role
CONN tt/tt
BEGIN -- use an anonymous block instead of a procedure
UPDATE scott.emp SET sal = sal;
END;
/ -- PL/SQL procedure successfully completed
60
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;
61
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;
62
Password Complexity Verification - Continued
 A DBA could construct a table (my_trojan_table) to collect usernames
and passwords each time a password is changed
CREATE TABLE my_trojan_table (
username VARCHAR2(30),password(30));
— 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
SELECT * FROM my_trojan_table;
USERNAME
PASSWORD
----------------AMY
AMYPWD
JOE
JOE_NEWPWD
63
The Role of Roles and Privileges
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
64
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
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
65
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"
,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#
-------1
92
GRANTEE
------------PUBLIC
FRED
privilege/role
priv no(+/-)
---------------- -----------SELECT ANY TABLE
-47 -- from system_privilege_map
DBA
4 –- from user$
66
Auditing Recent Privilege Grants (continued)
GRANT CREATE SYNONYM TO fred;
Fred is given privilege to create synonyms
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
Evidence of a recent grant
67
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
-----------PUBLIC
TT
PUBLIC
PUBLIC
PRIVILEGE
----------------------SELECT ANY TABLE
UNLIMITED TABLESPACE
SELECT ANY TRANSACTION
FLASHBACK ANY TABLE
ADM
--NO
NO
NO
NO
68
12c
Privilege Capture Views—Full List
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
69
Benefits of Privilege Analysis
 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
70
General Steps for Managing Privilege Analysis
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
71
Privilege Capture—Setup
 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
72
Completing the Privilege Capture
 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
OS_USER
MODULE
OBJ_PRIV
OBJECT_NAME
USED_ROLE
PATH
----------------CAPTURE
OS_USER
MODULE
OBJ_PRIV
OBJECT_NAME
USED_ROLE
PATH
:
:
:
:
:
:
:
CAPFRED
LTREE1\Administrator
SQL*Plus
SELECT
B
RF
FRED,RF
:
:
:
:
:
:
:
CAPFRED
LTREE1\Administrator
SQL*Plus
SELECT
D
FRED
FRED
“Verticalized” data from
dba_used_objprivs_path
Fred has used the rf role
to access amy’s b table
Fred has used the SELECT
privilege to access amy’s d table
73
The Role of Roles and Privileges (Summary)
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
74
The Role of Roles and Privileges
Carl Dudley
UKOUG Committee
Oracle ACE Director
[email protected]
Carl Dudley – Tradba Ltd
75