8.2 Installing Oracle Securely There are many approaches you can take to securing an operating system and database and an equal number of views on what really fulfills the definition of a "secure operating system." In a systems administration class we attended many years ago, the instructor drew a picture on the board. The picture was of a large room in which a very large computer and operator's console had been placed. There was only one door leading into the room and in front of that door, he drew a picture of a guard with a gun. He explained that he had just drawn a system that was quite secure: the only truly secure system is the system that allows no one to ever interact with the computer inside. A friend of ours describes his vision of the truly secure computer as "a computer in a lead-lined vault (no EMF emissions to be sniffed) with no network connections and a Marine guard with `shoot on sight' orders." Okay, these are not real-world solutions. However, both descriptions do bring home the point that as long as there are people interacting with a system, there is always the potential for a security breach. One of the most formidable threats to any system's security is the user who does not log off the system at night and does not have password protection on his terminal or personal computer. In this section, we'll look at ways of protecting logins to the system. 8.2.1 Security and the Operating System From the operating system perspective, security measures are used to protect access to files. On most operating systems, security is accomplished by creating specific groups of users with specific access rights defined for them. Each file within the directory can be granted different access restrictions. You might assign the ability to read from and write to one file while another file might receive read, write, and execute privileges or only read access, as you deem appropriate. For example, you might want the salesmen in your automobile dealership to be able to see what cars are in stock, so you give them read access to the car information. You might want your administrative assistants to enter information on the new cars as they arrive at your lot so you give them read and write privileges. Most database systems share this attribute with the Oracle database: no user has any need of any kind to directly access the database data files, or any of the installed database software (binaries, and in some cases, source code). The access to the database files is the responsibility and function of the database management system. Access to these files should always be severely restricted. In the following sections, we examine the various considerations for installing the Oracle software and creating an Oracle database. Because each operating system Oracle installation is potentially different, this discussion is not platform-specific. Oracle Corporation delivers operating system-specific guides for product installation, and we recommend that you read the guides supplied with your software and become very familiar with them. (We do show examples to make the discussion more tangible , however.) 8.2.2 Oracle and Operating System Authentication The standard Oracle access control mechanism is a database username and password combination, like the one you'd have with any computer system such as UNIX or with an Internet Service Provider (ISP). This allows access from any workstation that can successfully contact the computer running the database management system. In some implementations , however, identification and authentication at the point of access are more tightly controlled. There are several options in Oracle for achieving tighter access control. From Oracle version 7.x forward, the DBA has had two ways to provide authentication to the Oracle RDBMS: We'll discuss both of these in the sections that follow. If you use either one of these forms of access, you will not be prompted for a username or password when you go to access the system. To perform administration tasks as a DBA, if you want to administer one or more databases directly on the machine on which they reside, you will probably choose the operating system authentication approach. If you want to manage one or more databases from a remote client and you do not have a secure connection, you will probably use the password file approach. Either way, the use of the password file is reserved for highly privileged accounts to enable database tasks to be performed remotely. 8.2.2.1 The OSDBA and OSOPER roles Depending on the operating system you're using, there are two groups that can be created during installation of the Oracle software to provide operating system authentication for DBAs and operators. These groups (referred to in Oracle documentation as roles ), which are granted at the operating system level, are OSDBA (for DBAs) and OSOPER (for operators). They can have different names and different functionality depending on the operating system involved. We introduced these roles in Chapter 5. OSDBA is obviously used in conjunction with the DBA functions. The OSOPER group is used to indicate a person performing more restricted privileged actions in the database. Do not confuse the OSOPER group with any casual database user.  | In addition, don't confuse these operating system roles with the roles described in Chapter 5. These roles are not the same as the Oracle internal roles used to control access to various application objects. These operating system roles are used to enable a DBA or operator to perform database system functions. | | 8.2.2.2 From the operating system On a UNIX operating system, placing a user account in the DBA group enables that user to interact with the database to perform any functions the OSDBA role enables. Likewise, assigning a user to the OPERATOR system group enables that user to perform any tasks allowed within the OSOPER role. On a Digital UNIX system, for example, you can use the addgroup utility to create a group named "DBA." Likewise, you can create a group for the OSOPER with the same utility. By comparison, on an OpenVMS system, the operating system identifier ORA_DBA or ORA_<SID>_DBA is created and granted to any account that will perform DBA functions related to the OSDBA role. There does not seem to be an equivalent group for operators in an OpenVMS system. Any user who is placed in the operating system group, DBA, has the ability to connect to the database using the Server Manger Utility ( svrmgr ). When you issue a CONNECT INTERNAL command using svrmgrl (or svrmgrm on a UNIX system), in essence, you are connecting to the heart of the RDBMS as sys and can perform actions that could potentially damage the database. If you were a very new DBA, you might think you were connecting to a new database you were about to build, but might accidentally connect to a development or production database. If you were to execute a CREATE DATABASE command from the svrmgrl utility, your current database would be destroyed . Assigning a user access to the DBA group should, therefore, be done carefully and only after building a good business case for granting someone privileges that could jeopardize your production systems. If you want to limit the amount of privilege given to a user performing DBA tasks, you can create and customize your own roles. You do not need to make the decision at Oracle software installation time, and can take advantage of or disable these roles after installation. 8.2.2.3 OSOPER Generally, the OSOPER role has the ability to perform the following commands: - STARTUP
- SHUTDOWN
- ALTER DATABASE OPEN/MOUNT
- ALTER DATABASE BACKUP
- ARCHIVE LOG
- RECOVER
This role allows the user to enable RESTRICTED SESSION. The ability to perform any of these operations requires the user to have a much higher privilege level than the normal user or developer. 8.2.2.4 OSDBA The OSDBA role encompasses all the system privileges with the DBA role (explained in Chapter 5), the OSOPER role values, and the ability for the user to CREATE DATABASE and perform time-based recovery. The OSDBA and OSOPER groups can only be granted to a user through the operating system and cannot be granted, revoked , or dropped through the database. The method used for granting these groups is operating system-specific. If a user attempts to connect to the database from the operating system and the REMOTE_LOGIN_PASSWORD parameter in the database's INIT.ORA file is set to "NONE," Oracle will first attempt to connect using the OSDBA role. If that fails, Oracle will attempt to use the OSOPER role to connect. If both connection attempts fail, the connection will fail. 8.2.3 Operating System Accounts As we discussed in Chapter 7, there are several types of accounts that might be required for your system. This section examines more closely the types of operating system access required by a DBA or operator to perform various database system jobs. 8.2.3.1 Using CONNECT INTERNAL and CONNECT / In early versions of the Oracle RDBMS, in order to start up or shut down the database, you issued a command from the operating system command-line level. In a Windows NT environment, you can still start up or shut down the database by issuing the following commands: Net Start OracleStart<db_name> Net Stop OracleStart<db_name> Beginning in Oracle version 6.0, a new convention was introduced to enable you to connect to the database and issue interactive commands to perform database system work. In the earlier versions of the Oracle RDBMS version 6 and version 7.1.x the method of attaching to the database to perform tasks such as STARTUP, SHUTDOWN, and CREATE DATABASE was through a utility called SQLDBA . You entered the command CONNECT INTERNAL to connect to the database at a much more privileged level. Using the CONNECT INTERNAL mechanism, you attached to the database as sys and could perform these duties successfully. The tasks of starting up, shutting down, or creating a database cannot be accomplished directly from SQL*Plus even as the user sys . For version 7.2 and higher, the utility Oracle uses to perform these functions has changed. The new utility used is the Server Manager line mode ( svrmgrl ) and the connect string is one of the following: CONNECT INTERNAL AS SYSDBA CONNECT / AS SYSDBA CONNECT INTERNAL AS SYSOPER CONNECT / AS SYSOPER depending on the operating system group in which your account belongs. The unqualified command, CONNECT INTERNAL, is supported for backwards compatibility only and, on some operating systems, may cause errors to be written to the operating system console log. In version 7.2 or higher, in order to start a database, issue the following commands: svrmgrl CONNECT / AS SYSDBA STARTUP OPEN <db_name> EXIT | | From most operating systems, you cannot successfully issue this set of commands unless you have the OSOPER or OSDBA or equivalent operating system privileges. | | | 
