OCA/OCP Oracle Database 11g All-in-One Exam Guide 226 To change the default behavior: alter user jon default role none; Now when JON logs on, he will not have any roles enabled. Unfortunately, this means he can’t log on at all—because it is only HR_JUNIOR that gives him the CREATE SESSION system privilege. Easily fixed: SQL> grant connect to jon; Grant succeeded. SQL> alter user jon default role connect; User altered. SQL> select * from dba_role_privs where grantee='JON'; GRANTEE GRANTED_ROLE ADM DEF JON HR_JUNIOR NO NO JON CONNECT NO YES Now when JON connects, only his CONNECT role is enabled—and the current version of CONNECT is not dangerous at all. Within the application, software commands can be embedded to enable the HR_JUNIOR role. The basic command to enable a role within a session is SET ROLE rolename ; which can be issued by the user at any time. So no security yet. But if the role is created with this syntax: CREATE ROLE rolename IDENTIFIED USING procedure_name ; then the role can only be enabled by running the PL/SQL procedure nominated by procedure_name. This procedure can make any number of checks, such as checking that the user is working on a particular TCP/IP subnet; or that they are running a particular user process (probably not SQL*Plus); or that the time is in a certain range; and so on. Embedding calls to the enabling procedures at appropriate points in an application can switch roles on and off as required, while leaving them disabled at all times when a connection is made with an ad hoc SQL tool such as SQL*Plus. TIP It can be very difficult to work out why you can see certain data. You may have been granted the SELECT privilege on specific objects; you may have been granted the ALL privilege; you may have SELECT ANY; SELECT may have been granted to PUBLIC; or you may have a role to which SELECT has been granted. You may have all of these, in which case they would all have to be revoked to prevent you from seeing the data. Chapter 6: Oracle Security 227 PART I Exercise 6-3: Create and Grant Roles In this exercise, you will create some roles, grant them to the users, and demonstrate their effectiveness. 1. Connect to your database with SQL*Plus as user SYSTEM. 2. Create two roles as follows: create role usr_role; create role mgr_role; 3. Grant some privileges to the roles, and grant USR_ROLE to MGR_ROLE: grant create session to usr_role; grant select on sales.t1 to usr_role; grant usr_role to mgr_role with admin option; grant all on sales.t1 to mgr_role; 4. As user SYSTEM, grant the MGR_ROLE to WEBAPP: grant mgr_role to WEBAPP; 5. Connect to the database as user WEBAPP: connect webapp/oracle; 6. Grant the USR_ROLE to ACCOUNTS, and insert a row into SALES.T1: grant usr_role to accounts; insert into sales.t1 values(sysdate); commit; 7. Confirm the ACCOUNTS can connect and query SALES.T1 but do nothing else. The INSERT statement that follows should fail with an ORA-01031: insufficient privileges error. connect accounts/oracle select * from sales.t1; insert into sales.t1 values(sysdate); 8. As user SYSTEM, adjust ACCOUNTS so that by default the user can log on but do nothing else: connect system/oracle grant connect to accounts; alter user accounts default role connect; 9. Demonstrate the enabling and disabling of roles. The first time SALES tries to query the SALES.T1 table, it will receive an “ORA-00942: table or view does not exist” error. Once the USR_ROLE is activated, the same query succeeds. connect accounts/oracle select * from sales.t1; set role usr_role; select * from sales.t1; OCA/OCP Oracle Database 11g All-in-One Exam Guide 228 10. Use Database Control to inspect the roles. The navigation path from the database home page is: On the Server tab click the Roles link in the Security section. Click the links for the two new roles to see their privileges. This illustration shows the MGR_ROLE: 11. To see to whom a role has been granted, in the Actions drop-down box shown in the preceding illustration, select Show Grantees and click GO. This illustration shows the result for USR_ROLE: Chapter 6: Oracle Security 229 PART I 12. Obtain the same information retrieved in Steps 10 and 11 with these queries: select * from dba_role_privs where granted_role in (‘USR_ROLE','MGR_ROLE'); select grantee,owner,table_name,privilege,grantable from dba_tab_privs where grantee in (‘USR_ROLE','MGR_ROLE') union all select grantee,to_char(null),to_char(null),privilege,admin_option from dba_sys_privs where grantee in (‘USR_ROLE','MGR_ROLE') order by grantee; Create and Manage Profiles A profile has a dual function: to enforce a password policy and to restrict the resources a session can consume. Password controls are always enforced; resource limits are only enforced if the instance parameter RESOURCE_LIMIT is on TRUE—by default, it is FALSE. Profiles are used automatically, but the default profile (applied by default to all users, including SYS and SYSTEM) does very little. EXAM TIP Profile password limits are always enforced; profile resource limits are enforced only if the instance parameter RESOURCE_LIMIT is TRUE. Password Management The limits that can be applied to passwords are • FAILED_LOGIN_ATTEMPTS Specifies the number of consecutive errors on a password before the account is locked. If the correct password is given before this limit is reached, the counter is reset to zero. • PASSWORD_LOCK_TIME The number of days to lock an account after FAILED_LOGIN_ATTEMPTS is reached. • PASSWORD_LIFE_TIME The number of days before a password expires. It may still be usable for a while after this time, depending on PASSWORD_ GRACE_TIME. • PASSWORD_GRACE_TIME The number of days following the first successful login after the password has expired that prompts to change the password will be generated. The old password is still usable during this time. • PASSWORD_REUSE_TIME The number of days before a password can be reused. • PASSWORD_REUSE_MAX The number of times a password can be reused. • PASSWORD_VERIFY_FUNCTION The name of a function to run whenever a password is changed. The purpose of the function is assumed to be checking the new password for a required degree of complexity, but it can do pretty much anything you want. OCA/OCP Oracle Database 11g All-in-One Exam Guide 230 Resource Limits The limits that can be applied to resource usage (also known as kernel limits) are • SESSIONS_PER_USER The number of concurrent logins that can be made to the same user account. Sessions attempting to log in with the same user name when this limit is reached will be blocked. • CPU_PER_SESSION The CPU time (in centiseconds) that a session’s server process is allowed to use before the session is forcibly terminated. • CPU_PER_CALL The CPU time (in centiseconds) that a session’s server process is allowed to use to execute one SQL statement before the statement is forcibly terminated. • LOGICAL_READS_PER_SESSION The number of blocks that can be read by a session (irrespective of whether they were in the database buffer cache or read from disk) before the session is forcibly terminated. • LOGICAL_READS_PER_CALL The number of blocks that can be read by a single statement (irrespective of whether they were in the database buffer cache or read from disk) before the statement is forcibly terminated. • PRIVATE_SGA For sessions connected through the shared server architecture, the number of kilobytes that the session is allowed to take in the SGA for session data. • CONNECT_TIME In minutes, the maximum duration of a session before the session is forcibly terminated. • IDLE_TIME In minutes, the maximum time a session can be idle before the session is forcibly terminated. • COMPOSITE_LIMIT A weighted sum of CPU_PER_SESSION, CONNECT_ TIME, LOGICAL_READS_PER_SESSION, and PRIVATE_SGA. This is an advanced facility that requires configuration beyond the scope of the OCP examination. Resource limits will not be applied unless an instance parameter has been set: alter system set resource_limit=true; This defaults to FALSE. When a session is terminated because a resource limit has been reached, if there was a transaction in progress it will be rolled back. If a statement is terminated, the work done by the statement will be rolled back, but any earlier statements will remain intact and uncommitted. TIP Profiles can be used to limit resource usage, but a much more sophisticated tool is the Resource Manager discussed in Chapter 21. Chapter 6: Oracle Security 231 PART I Creating and Assigning Profiles Profiles can be managed through Database Control or from SQL*Plus. To see which profile is currently assigned to each user, run this query: select username,profile from dba_users; By default, all users (with the exception of two internal users, DBSNMP and WKSYS) will be assigned the profile called DEFAULT. Then the view that will display the profiles themselves is DBA_PROFILES: select * from dba_profiles where profile='DEFAULT'; Or with Database Control, from the database home page take the Server tab, and then click the Users link in the Security section to see which profile each user has. Select a user and click EDIT to assign a different profile. To see how the profiles are set up, click the Profiles link in the Security section. The DEFAULT profile has no resource limits at all, but there are some password limits: Resource Name Limit FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 1 PASSWORD_LIFE_TIME 180 PASSWORD_GRACE_TIME 7 These restrictions are not too strict: a password can be entered incorrectly ten consecutive times before the account is locked for one day, and a password will expire after about six months with a one-week grace period for changing it after that. The simplest way to enable more sophisticated password management is to run the Oracle-supplied script. On Unix or Linux it is $ORACLE_HOME/rdbms/admin/utlpwdmg.sql On Windows it is %ORACLE_HOME%\rdbms\admin\utlpwdmg.sql On either platform, the script creates two functions called VERIFY_FUNCTION and VERIFY_FUNCTION_11G, and runs this command: ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 180 PASSWORD_GRACE_TIME 7 PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 1 PASSWORD_VERIFY_FUNCTION verify_function_11G; OCA/OCP Oracle Database 11g All-in-One Exam Guide 232 This command will adjust the profile called DEFAULT. Any users with the DEFAULT profile (which is all users, by default) will immediately pick up the new values. Following a standard database creation, the only change will be the specification of the PASSWORD_ VERIFY_FUNCTION. The function nominated, VERIFY_FUNCTION_11G, makes a set of simple tests and will reject a password change if it does not pass all of them: • The new password must be at least eight characters long. • The new password cannot be the same as the username (spelled backward or forward) or the name of the database, in upper- or lowercase. • A few simple and commonly used passwords (such as “oracle”) will be rejected. • The new password must have at least one letter and at least one digit. • The password must differ in at least three characters from the preceding password. The script should be viewed as an example script (certainly the function is very elementary) and should be edited to suit the needs of the organization. Most organizations will need to go further than this and create a set of profiles to be applied to different users. To create a profile with SQL*Plus, use the CREATE PROFILE command, setting whatever limits are required. Any limits not specified will be picked up from the current version of the DEFAULT profile. For example, it could be that the rules of the organization state that no users should be able to log on more than once, except for administration staff, who can log on as many concurrent sessions as they want and must change their passwords every week with one-day grace, and the programmers, who can log on twice. To do this, first adjust the DEFAULT profile: alter profile default limit sessions_per_user 1; Create a new profile for the DBAs, and assign it: create profile dba_profile limit sessions_per_user unlimited password_life_time 7 password_grace_time 1; alter user system profile dba_profile; Create a profile for the programmers, and assign it: create profile programmers_profile limit sessions_per_user 2; alter user jon profile programmers_profile; alter user sue profile programmers_profile; To let the resource limit take effect, adjust the instance parameter: alter system set resource_limit=true; Assuming that the instance is using an SPFILE, this change will be propagated to the parameter file and will therefore be permanent. A profile cannot be dropped if it has been assigned to users. They must be altered to a different profile first. Once done, drop the profile with DROP PROFILE profile_name ; Chapter 6: Oracle Security 233 PART I Alternatively, use this syntax: DROP PROFILE profile_name CASCADE ; which will automatically reassign all users with profile_name back to the DEFAULT profile. Exercise 6-4: Create and Use Profiles In this exercise, create, assign, and test a profile that will force some password control. 1. Connect to your database with SQL*Plus as user system. 2. Create a profile that will lock accounts after two wrong passwords: create profile two_wrong limit failed_login_attempts 2; 3. Assign this new profile to SALES: alter user sales profile two_wrong; 4. Deliberately enter the wrong password for SALES a few times. You will get an “ORA-28000: the account is locked” message after the third failed attempt. connect sales/wrongpassword 5. As user SYSTEM, unlock the SALES account: alter user sales account unlock; 6. Check that SALES can now connect: connect sales/oracle The next illustration shows the sequence of events. OCA/OCP Oracle Database 11g All-in-One Exam Guide 234 7. Tidy up by dropping the profile, the roles, and the users. Note the use of CASCADE when dropping the profile to remove it from SALES, and on the DROP USER command to drop their table as well. Roles can be dropped even if they are assigned to users. The privileges granted on the table will be revoked as the table is dropped. connect system/oracle drop profile two_wrong cascade; drop role usr_role; drop role mgr_role; drop user sales cascade; drop user accounts; drop user webapp; Database Security and Principle of Least Privilege The safest principle to follow when determining access to computer systems is that of least privilege: no one should have access to anything beyond the absolute minimum needed to perform their work, and anything not specifically allowed is forbidden. The Oracle database conforms to this, in that by default no one can do anything at all, with the exception of the two users SYS and SYSTEM. No other users can even connect—not even those created by the standard database creation routines. In addition to the use of password profiles, there are best practices that should be followed to assist with implementing the least-privilege principle, particularly regarding privileges granted to the PUBLIC account and certain instance parameters. Public Privileges The PUBLIC role is implicitly granted to every user. Any privileges granted to PUBLIC have, in effect, been granted to everyone who can connect to the database; every account you create will have access to these privileges. By default, PUBLIC has a large number of privileges. In particular, this role has execute permission on a number of PL/SQL utility packages, as shown in Figure 6-9. You should always consider revoking the execution privileges on the UTL packages, but remember that application software may assume that the privilege is there. Execution privilege may be revoked as follows: SQL> revoke execute on utl_file from public; Some of the more dangerous packages listed in Figure 6-9 are • UTL_FILE Allows users to read and write any file and directory that is accessible to the operating system Oracle owner. This includes all the database files, and the ORACLE_HOME directory. On Windows systems, this is particularly dangerous, as many Windows databases run with Administrator privileges. The package is to a certain extent controlled by the UTL_FILE_DIR instance parameter, discussed in the next section. Chapter 6: Oracle Security 235 PART I • UTL_TCP Allows users to open TCP ports on the server machine for connections to any accessible address on the network. The interface provided in the package only allows connections to be initiated by the PL/SQL program; it does not allow the PL/SQL program to accept connections initiated outside the program. Nonetheless, it does allow malicious users to use your database as the starting point for launching attacks on other systems, or for transmitting data to unauthorized recipients. • UTL_SMTP Written using UTL_TCP calls, this package lets users send mail messages. It is restricted by the UTL_SMTP_SERVER instance parameter, which specifies the address of the outgoing mail server, but even so you probably do not want your database to be used for exchange of mail messages without your knowledge. • UTL_HTTP Allows users to send HTTP messages and receive responses—in effect, converting your database into a web browser. This package also makes use of UTL_TCP subprograms. Always remember that, by default, these packages are available to absolutely anyone who has a logon to your database, and furthermore that your database may have a number of well-known accounts with well-known passwords. EXAM TIP PUBLIC is a role that is granted to everyone—but when connecting to the instance using the AS SYSOPER syntax, you will appear to be connected to an account PUBLIC. Security-Critical Instance Parameters Some parameters are vital to consider for securing the database. The defaults are usually fine, but in some circumstances (for which there should always be a good business case), you may need to change them. All of the parameters described here Figure 6-9 Privileges granted to PUBLIC . from sales.t1; OCA/ OCP Oracle Database 11g All-in-One Exam Guide 228 10. Use Database Control to inspect the roles. The navigation path from the database home page is: On the Server tab click. into a web browser. This package also makes use of UTL_TCP subprograms. Always remember that, by default, these packages are available to absolutely anyone who has a logon to your database, and. account: alter user sales account unlock; 6. Check that SALES can now connect: connect sales /oracle The next illustration shows the sequence of events. OCA/ OCP Oracle Database 11g All-in-One Exam