Hardening Oracle Database with Oracle Solaris Security ... · Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies 1 Introduction This white paper

An Oracle White Paper

August 2010

Hardening Oracle Database with Oracle Solaris Security Technologies

Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies

Introduction ......................................................................................... 1!

Containment........................................................................................ 2!

Operating System Virtualization...................................................... 2!

Containment Through File System Configuration ........................... 5!

Least Privilege .................................................................................... 6!

User Rights Management ............................................................... 7!

Process Rights Management........................................................ 10!

Service Management ........................................................................ 13!

Locking Down Oracle with Auditing .................................................. 15!

Configuring the System for Audit .................................................. 16!

Determining What to Audit ............................................................ 16!

Configuring the Audit .................................................................... 17!

Securing the Audit......................................................................... 18!

Enable Auditing............................................................................. 19!

Viewing the Audit Log ................................................................... 19!

Stopping and Starting the Audit .................................................... 23!

Conclusion ........................................................................................ 24!

References........................................................................................ 24!


1

Introduction

This white paper describes and demonstrates how commodity Oracle Solaris operating system

security features can be used to lock down network-facing services in order to protect them

against internal and external threats. Technology concepts and their realizations are presented

in a hands-on fashion using a running example: Oracle Database Server 11g Release 2

executing on Oracle Solaris 10 10/09.

While the Oracle Solaris operating system contains a large ecosystem of security

mechanisms, this document focuses on a few that are especially powerful when it comes to

protecting network-facing services. It explores the mechanisms in several categories:

• Containment, through operating system virtualization and file system configuration

• Least privilege, through Oracle Solaris role-based access control and privileges

• Reliability and availability, through the Oracle Solaris Service Management Facility

• Accountability, through auditing


2

Containment

Containment is a methodology in which computing assets such as data, processes, or files are grouped

within a well-defined perimeter. It is often loosely referred to as sandboxing. Crossing the perimeter is

carefully controlled by mechanisms such as well-defined interfaces or access points that enforce

security policies. Such perimeters can exist at any level of granularity, from computer networks

surrounded by firewalls to object instances in an object-oriented programming environment.

Containment works in both directions. While access to objects within a perimeter is guarded, those

objects cannot escape their sandbox unless explicitly allowed. The latter protects the environment from

damage inside the perimeter as well as danger originating from the contained entities. It also can help

enforce confidentiality requirements.

Containment strategies that are employed in a hierarchical fashion contribute to defense in depth.

There are several well-known examples of security technologies that are based on containment. For

example, in firewall technology an entire network policy domain is the unit of containment. In Java

Virtual Machine, Java byte codes are executed in an environment with well-defined and carefully

controlled resource access.

Operating System Virtualization

The Oracle Solaris operating system offers a built-in, lightweight virtualization technology in which

multiple Oracle Solaris user space instances, called Oracle Solaris Containers, share a single kernel. This

technology provides a coarse-grained containment mechanism that offers all the security benefits of

containment in the form of a familiar abstraction: the UNIX® user space environment. It can be

thought of as an advanced extension of the UNIX chroot mechanism ([7]). A zone is simply a virtual

operating system abstraction that provides a protected environment in which applications run isolated

from other applications on the system. A special zone in each system, called the global zone, is the

parent of all non-global zones. Non-global zones are managed by global zone administrators.

Operating system (OS) level virtualization allows multiple applications to share the same operating

system instance while providing separate security domains for each application. In an OS virtualized

environment, the kernel provides multiple isolated user space instances. Zones look and feel to users

and administrators like separate operating system instances. Fine-grained resource management of

CPUs, memory, and network bandwidth limits the amount of resources that can be consumed by

applications within zones. Such application containment provides a variety of security advantages.

• Damage caused by an application isolated in a zone remains contained within that zone, as if the

application ran on a dedicated machine. In other words, applications in different zones are protected

from each other to provide software fault isolation.

• Applications that execute in zones cannot interact with privileged system processes or resources, as a

limited set of privileges are available to them. They cannot escape from zones or observe or signal

processes in other zones. There is no shared memory or inter-process communication available

across zone boundaries.


3

• Individual zones can instantiate their own network security policies when configured to use exclusive

Internet Protocol (IP) stack instances by employing their own Internet Protocol Security (IPSec),

packet filtering, and virtual LAN (VLAN) security policies.

• Each zone has its own instance of the Oracle Solaris Service Management Facility, aiding the

reduction of system attack surfaces through the minimization of externally facing services. A

discussion of the Oracle Solaris Service Management Facility can be found in the Service

Management section of this document.

• Zones are the primary mechanism used to implement data separation in Oracle Solaris Trusted

Extensions, an advanced security feature that implements labels to protect data and applications

based on their sensitivity level, not just who owns or runs them.

In addition, Oracle Solaris offers a type-1 hypervisor technology on the sun4v architecture of the

SPARC® processor series, called Oracle VM Server for SPARC. For defense in depth, the sample

system described in this document also can be deployed inside a domain. A discussion of when to use

this additional layer of virtualization is beyond the scope of this document.

Figure 1, Figure 2, and Figure 3 illustrate three deployment architectures. Figure 1 shows how a service

is deployed in a traditional UNIX system. In this figure, host ozone has three architectural layers:

hardware and hypervisor, operating system, and user space. The database service process(es) here are

denoted generically as a service. They execute in the user space with the user id oracle, an

established way to run services with reduced privileges. The service communicates with the outside

world over a network interface. In the example, the network interface is named nic0.

Figure 1. Service deployed in a traditional UNIX system architecture

Figure 2 shows how a service is deployed inside a zone in an OS virtualized environment. In this

diagram, the Oracle database service runs inside a non-global zone, named ozone. While zone ozone

(with associated host name ozone) is displayed side-by-side with the global zone (with associated host

name paris), its powers compared to the global zone are greatly reduced. Both zones share the same

operating system kernel image. However, the Oracle Solaris privilege model restricts non-global zones

by capping their process privilege limit sets. That means even root processes executing inside a non-

global zone cannot affect the global zone or any system resources or processes that belong to other


4

zones. The Oracle Solaris privilege model is explained in detail in chapters 5.2 and 11.4.4 of [1].

Reference [4] describes in detail how zones are created, installed, and managed.

Figure 2. Service deployed in operating system virtualized (zoned) architecture

The configuration illustrated in Figure 2 is shown via shell commands below.

tstark@paris:~$ zoneadm list -cv

ID NAME STATUS PATH BRAND IP

0 global running / native shared

1 ozone running /zone/ozone native shared

tstark@paris:~$ ssh -X -l jdoe ozone

Password:

Last login: Wed Oct 28 16:51:35 2009 from paris

Sun Microsystems Inc. SunOS 5.11 snv_125 November 2008

jdoe@ozone:~$

The output of the zoneadm!list!-cv command (zoneadm(1M)) shows two running zones: the global

zone with ID 0, and the non-global zone named ozone with ID 1. The root path name for the global

zone is /, and the root pathname for the non-global zone named ozone is /zone/ozone. The second

path name is equivalent to the traditional chroot directory. That means every process executing within

zone ozone only can access file system contents relative to the directory /zone/ozone/root that

appears to be the root directory.

Example 1 shows user jdoe logging in to the non-global zone ozone from the global zone (with host

name paris.) The ssh command is used because sshd is the only remote terminal service accessible

on Oracle Solaris by default. There is no apparent difference to user jdoe between logging into a non-

global zone and logging into a standalone server.

Furthermore, Figure 2 indicates the service no longer is run under the user id oracle, but a role of the

same name. Similarly, as indicated in the global zone, there is no longer a superuser account (root) on


5

the entire system — root is a role that authorized users can assume. The Least Privilege section

explains the role-based access control (RBAC) model in Oracle Solaris, particularly the advantages of

roles over regular user accounts.

Figure 3 shows how a system is deployed inside a domain created by Oracle VM Server for SPARC.

Figure 3. Operating system virtualized images together with the surrounding operating system deployed inside a domain created by Oracle VM

Server for SPARC

Containment Through File System Configuration

Further containment can be observed in an Oracle Solaris ZFS file system configuration. The example

in this document uses Oracle Solaris ZFS as the root file system for the global zone, with a dataset

under the control of the zone.

The Oracle Solaris ZFS file system offers many advantages over

traditional file systems, including instantaneous snapshots and

clones, and delegation of administrative rights. An Oracle Solaris

ZFS dataset is a lightweight file system abstraction that can include

an explicit mount point and a compression factor, and can be used in many cases like traditional

directories. For example, each user's home directory can be managed as a separate Oracle Solaris ZFS

dataset. Individual users can be delegated the rights to take archival snapshots, and to revert to earlier

versions of files. Similarly, database instances can be archived via snapshots.

Oracle Solaris zones are optimized to use Oracle Solaris ZFS. Each zone is installed in its own dataset,

and snapshots of the datasets for installed zones can be used to clone new zones. When installing or

cloning a zone, the zoneadm command automatically creates a new dataset if the parent directory

corresponds to an Oracle Solaris ZFS dataset. The parent dataset for all zones is created as follows.

root@paris:~# zfs create -o mountpoint=/zone rpool/zones

If a global zone uses a UFS root file

system, users can create Oracle

Solaris ZFS file systems for a zone

using dedicated disk drives.


6

Dataset names are hierarchical, like directory pathnames. The difference is that the first component in

the path is the name of the storage pool, called a zpool. When zone ozone is installed its dataset,

rpool/zones/ozone is mounted on /zone/ozone. This corresponds to /, the root directory, when

viewed from within the zone.

In order to provide the benefits of Oracle Solaris ZFS to users within the zone, additional datasets can

be delegated for use within the zone. This is done within the global zone as follows. The dataset

appears in the zone when it is booted, and is mounted on /u01. Oracle Database 11g then can be

installed.

root@paris:~# zoneadm -z ozone halt

root@paris:~# zfs create -o zoned=on -o mountpoint=/u01 rpool/zones/ozone/zfs01

root@paris:~# zonecfg -z ozone

zonecfg:ozone> add dataset

zonecfg:ozone:dataset> set name=rpool/zones/ozone/u01

zonecfg:ozone:dataset> end

zonecfg:ozone> exit

root@paris:~# zoneadm -z ozone boot

root@paris:~# zlogin ozone

Snapshots and clones of this dataset can be managed from within the zone. The rights to create and

manage these snapshots can be delegated to the oracle role as shown below. Once granted, the

Oracle role is authorized to execute Oracle Solaris ZFS sub-commands on the specified dataset and its

children. For example, periodic snapshots can be taken in real time. If necessary, the database can be

reverted to a previous state by promoting the snapshot to the parent dataset.

root@ozne:~# zfs allow oracle clone,create,destroy,mount,snapshot,promote \

rpool/zones/ozone/zfs01

Least Privilege

In today's systems, it is important to have different levels of access for different types of

administration, and to record who performed what action. For this reason, the old UNIX model of an

all-powerful root user no longer suffices. This is in accordance with the security principle of least

privilege that demands that every program and user of the system operate using the smallest set of

privileges necessary to complete the job. The solution in the Oracle Solaris operating system is the use

of roles for specific administrative tasks. Users only can assume the roles for which they are

authorized. Rights profiles are created and assigned to roles to specify which tasks a role can perform.

Starting with Oracle Solaris 10, the operating system implements a set of privileges that provide fine-

grained control over the actions of processes. For each privileged operation, such as accessing raw

network devices or mounting a file system, the kernel validates that the process performing the

operation has been assigned the required privilege. The use of fine-grained privileges is discussed in

more detail later in this section.


7

User Rights Management

Role-based access control (RBAC) [3] is an approach that restricts system access to authorized users

based on their individual job function (called a role.) In Oracle Solaris, a role is instantiated as a normal

user account carrying one important restriction. A role cannot log into a system, it can only be assumed

using the su(1M) command by a user who is already logged in to the system. For example, the

auditor role can be assumed by the authorized user tstark to configure and review auditing. In

addition, roles are managed by a system administrator and can be shared among users.

There are a number of benefits to using roles. The RBAC mechanism in Oracle Solaris provides a very

flexible and simple means to assign rights for privileged actions to users in a fine-grained manner. The

superuser role is decomposed into distinct roles. Individual rights are specified using hierarchical

profiles and authorizations. Administrative actions are audited based on user identifiers, not role

identifiers. In other words, in a traditional UNIX environment where multiple administrators knew the

root password, administrative actions by one superuser could not be attributed to a single person. With

Oracle Solaris, however, privileged actions always are attributed in the audit trail to the user assuming

the administrative role.

Consider the sample configuration depicted in Figure 4.

Figure 4. User and role hierarchy in the global zone

The following example shows the contents of the RBAC files for this configuration.


8

tstark@paris:~$ grep auditor /etc/passwd

auditor:x:100:1::/export/home/auditor:/usr/bin/bash

tstark@paris:~$ grep auditor /etc/user_attr

auditor::::type=role;profiles=Audit Review,Audit Control

tstark::::type=normal;roles=root,auditor;

tstark@paris:~$ grep Audit /etc/security/prof_attr

Audit Control:::Configure BSM auditing:\

auths=solaris.audit.config,solaris.jobs.admin,solaris.admin.logsvc.purge,\

solaris.admin.logsvc.read;help=RtAuditCtrl.html

Audit Review:::Review BSM auditing logs:\

auths=solaris.audit.read;help=RtAuditReview.html

tstark@paris:~$ grep Audit /etc/security/exec_attr

Audit Control:suser:cmd:::/etc/security/bsmconv:uid=0

Audit Control:suser:cmd:::/etc/security/bsmunconv:uid=0

Audit Control:suser:cmd:::/usr/sbin/audit:euid=0

Audit Control:suser:cmd:::/usr/sbin/auditconfig:euid=0

Audit Control:suser:cmd:::/usr/sbin/auditd:uid=0

Audit Review:suser:cmd:::/usr/sbin/auditreduce:euid=0

Audit Review:suser:cmd:::/usr/sbin/auditstat:euid=0

Audit Review:suser:cmd:::/usr/sbin/praudit:euid=0

The following example shows the output of some RBAC commands executed by tstark in the global

zone.

tstark@paris:~$ id

uid=101(tstark) gid=1(other)

tstark@paris:~$ roles

root,auditor

tstark@paris:~$ profiles -l auditor

Audit Review:

/usr/sbin/auditreduce euid=0

/usr/sbin/auditstat euid=0

/usr/sbin/praudit euid=0

Audit Control:

/etc/security/bsmconv uid=0

/etc/security/bsmunconv uid=0

/usr/sbin/audit euid=0

/usr/sbin/auditconfig euid=0

/usr/sbin/auditd uid=0

All:

*

tstark@paris:~$ auths auditor

solaris.audit.read,solaris.audit.config,...


9

RBAC also is used in the ozone zone. For example, the ozone zone is configured such that an

authorized user (jdoe) must assume the role oracle to start, stop, or administer Oracle database

related services (Figure 5).

Figure 5. User and role hierarchy in the ozone zone.

The example below shows the contents of the RBAC files for this configuration in zone ozone.

jdoe@ozone:~$ egrep jdoe|oracle /etc/passwd

jdoe:x:65535:10:John Demo:/export/home/jdoe:/bin/bash

oracle:x:65537:100:Oracle Role Account:/export/home/oracle:/bin/bash

jdoe@ozone:~$ grep jdoe|oracle /etc/user_attr

oracle::::type=role;profiles=Oracle Management;defaultpriv=basic,!proc_info

jdoe::::type=normal;roles=oracle;defaultpriv=basic,!proc_info

jdoe@ozone:~$ grep Oracle /etc/security/prof_attr

Oracle Management:::Manage the Oracle Software:auths=solaris.smf.manage.\

oracle.database,solaris.smf.manage.oracle.listener;help=none.html

The /etc/passwd file in zone ozone and in the global zone contains the user and role definition for

user jdoe and role oracle, and user tstark and role auditor, respectively. See passwd(4)for

more information.

• The /etc/user_attr file is the local source for extended attributes associated with users and roles.

In this example, it specifies that oracle is of type=role, and that the role oracle contains the

Oracle Management execution profile. The following line shows the entry for jdoe, a normal user

account that is authorized to assume the oracle role (roles=oracle). It has the typical user

account execution profile, Basic Solaris User. See userattr(4)for more information.


10

• While the /etc/security/prof_attr file contains locally defined execution profile names,

descriptions, and other attributes of execution profiles, the /etc/security/exec_attr file

specifies the execution attributes associated with profiles. See prof_attr(4) and exec_attr(4)

for more information.

In UNIX, the Oracle database software traditionally is installed and run with the oracle user id. In

this example, the user id oracle was not created. Instead, an oracle role was created. Users that need

to be able to administer the Oracle database are authorized to assume the oracle role, such as user

jdoe@ozone. In Oracle Solaris, roles are assigned execution profiles, a mechanism used to bundle the

commands and authorizations needed to perform a specific function. Figure 5 lists the execution path

names and attributes for the Oracle Management execution profile.

Authorizations are unique strings that represent a user’s or role’s right to perform an operation or class

of operations. Authorization definitions are stored in the /etc/security/auth_attr database. Two

authorizations are defined in the example: solaris.smf.manage.oracle.database and

solaris.smf.manage.oracle.listener. For programmatic authorization checks, only the

authorization name is significant. The Oracle Solaris Service Management Facility that is responsible

for managing service instances in Oracle Solaris checks programmatically to see if a user has those

authorizations based on the role and execution profiles. See roleadd(1m) and authattr(4) for

more information.

Process Rights Management

There are two facets to the principle of least privilege in Oracle Solaris: limiting what users and

processes are allowed to do. The User Rights Management section addressed how to limit a user's

privileges. This section addresses how to limit a the privileges for a process.

Beginning with Oracle Solaris 10, all operations that were previously guarded by checks for user ID

zero have been investigated and categorized. This resulted in a breakdown of super-user powers into a

large number of operation-specific privileges (approximately 68 in the Oracle Solaris 10 10/09 release).

Names indicate their purpose. For example, a process that is granted the proc_info privilege is

allowed to examine the status information of processes.

Oracle Solaris uses privilege sets that can be empty or contain a number of privileges. Each process is

associated with four privilege sets.

• The effective set contains the privileges a process is currently using. It is analogous to the effective UID

in the traditional UNIX model.

• The permitted set contains the privileges a process can put into effect.

• The inheritable set contains the privileges that can be carried over to child processes.

• The limit set contains an upper limit on which privileges a process and its offspring can obtain.

Every privileged operation in Oracle Solaris is validated. The OS verifies that the user performing the

operation is assigned the specific privilege required to perform the operation. For backwards

compatibility, five privileges are granted to all new users in the basic set: file_link_any,


11

proc_exec, proc_fork, proc_info, and proc_session. These privileges allow users to do

everything they used to be able to do on previous versions of the OS, freeing system administrators

from dealing with privileges until they are ready to do so.

By understanding the process privileges that are available, administrators can fine-tune a user or role so

they have just the right amount of privileges they need to get the job done. This may include adding

additional privileges or removing privileges from the basic set. For example, the oracle role can be

kept from viewing process information. This can be accomplished by removing the proc_info

privilege granted as part of the basic set.

Take a look at the privilege sets granted to the shell of the oracle role. The Oracle shell is running as

process ID 4048. It is a Bourne again shell (bash). The process has no flags, indicating it is a non

privilege-aware (NPA) process. In other words, the bash process runs without modifications in a

backwards compatible manner. This is currently the case with most Oracle Solaris processes.

oracle@ozone:~$ ppriv -S $$

4048: -bash

flags = <none>

E: basic

I: basic

P: basic

L: zone

Privilege-aware (PA) programs can take better advantage of Oracle Solaris privilege features by

manipulating the various privilege sets programmatically. At the beginning of execution, a privilege-

aware program can eliminate any privileges that are not needed. Throughout execution, the program

can bracket privileged operations and relinquish privileges when they are no longer needed. For

example, the ISCSI Initiator is a privilege-aware process. The ISCSI Initiator, which historically ran

with root privileges, now runs with only the basic privilege set plus the sys_devices privilege.

root@paris:~# ppriv -S `pgrep iscsid`

309: /lib/svc/method/iscsid

flags = PRIV_AWARE

E: basic,sys_devices

I: basic,sys_devices

P: basic,sys_devices

L: all

A description of a privilege can be obtained by using the ppriv command.

root@paris:~# ppriv -lv sys_devices

sys_devices

Allows a process to successfully call a kernel module that

calls the kernel drv_priv(9F) function to check for allowed access.

Allows a process to open the real console device directly.

Allows a process to open devices that have been exclusively opened.


12

The limit set defines the upper limit of which privileges can be used, even by the most powerful

processes. For example, even a root process inside a zone cannot load a kernel module, as the required

privileges are never available to any process executing in a zone context.

Since the oracle role has the basic set of privileges, it is allowed to view all the processes on the

system.

oracle@ozone:~$ ps -ef | more

UID PID PPID C STIME TTY TIME CMD

oracle 4726 1305 0 14:55:47 ? 0:00 ora_diag_ORCL

root 4593 1695 0 14:44:29 ? 0:00 /usr/lib/ssh/sshd

oracle 4617 4605 0 14:45:34 pts/7 0:00 -bash

oracle 5160 1305 0 14:56:12 ? 0:00 ora_arc0_ORCL

oracle 4718 1305 1 14:55:46 ? 0:00 ora_pmon_ORCL

jdoe 4594 4593 0 14:44:29 ? 0:00 /usr/lib/ssh/sshd

oracle 4720 1305 1 14:55:46 ? 0:00 ora_vktm_ORCL

jdoe 4605 4594 0 14:44:32 pts/7 0:00 -bash

oracle 4724 1305 0 14:55:47 ? 0:00 ora_gen0_ORCL

root 1695 1305 0 18:01:14 ? 0:00 /usr/lib/ssh/sshd

root 1305 1305 0 18:00:25 ? 0:00 zsched

root 1322 1305 0 18:00:26 ? 0:00 /sbin/init

root 1326 1305 0 18:00:27 ? 0:37 /lib/svc/bin/svc.configd

root 1324 1305 0 18:00:27 ? 0:16 /lib/svc/bin/svc.startd

daemon 1568 1305 0 18:01:00 ? 0:00 /usr/lib/nfs/lockd

root 1399 1305 0 18:00:48 ? 0:14 /usr/sbin/nscd

root 1765 1305 0 18:01:17 ? 0:00 /usr/lib/dmi/snmpXdmid -s ozone

smmsp 1730 1305 0 18:01:15 ? 0:00 /usr/lib/sendmail -Ac -q15m

root 1678 1305 0 18:01:12 ? 0:00 /usr/lib/autofs/automountd

root 1595 1305 0 18:01:01 0:00 /usr/sadm/lib/smc/bin/smcboot

This access is granted by the proc_info privilege.

oracle@ozone:~$ ppriv -lv proc_info

proc_info

Allows a process to examine the status of processes other

than those it can send signals to. Processes which cannot

be examined cannot be seen in /proc and appear not to exist.

If administrators want to prevent the oracle role from having this privilege, the account can be

modified as follows.

# rolemod -K defaultpriv=basic,!proc_info oracle


13

When the oracle role runs the ps command, it can see only the processes it owns.

oracle@ozone:~$ ps -ef

UID PID PPID C STIME TTY TIME CMD

oracle 4726 1305 0 14:55:47 ? 0:01 ora_diag_ORCL


oracle 4718 1305 0 14:55:46 ? 0:03 ora_pmon_ORCL

oracle 4720 1305 0 14:55:46 ? 0:02 ora_vktm_ORCL

oracle 4724 1305 0 14:55:47 ? 0:01 ora_gen0_ORCL

oracle 4728 1305 0 14:55:47 ? 0:01 ora_dbrm_ORCL

oracle 4730 1305 0 14:55:48 ? 0:02 ora_psp0_ORCL


oracle 4732 1305 0 14:55:48 ? 0:03 ora_dia0_ORCL

oracle 4734 1305 0 14:55:48 ? 0:07 ora_mman_ORCL

oracle 4736 1305 0 14:55:49 ? 0:03 ora_dbw0_ORCL

oracle 4738 1305 0 14:55:49 ? 0:03 ora_lgwr_ORCL

oracle 4740 1305 0 14:55:49 ? 0:04 ora_ckpt_ORCL

oracle 4742 1305 0 14:55:50 ? 0:03 ora_smon_ORCL

oracle 4744 1305 0 14:55:50 ? 0:01 ora_reco_ORCL

oracle 4746 1305 0 14:55:50 ? 0:05 ora_mmon_ORCL

oracle 4748 1305 0 14:55:51 ? 0:03 ora_mmnl_ORCL

oracle 4750 1305 0 14:55:51 ? 0:01 ora_d000_ORCL

Administrators may need to understand which privilege is limiting the ability to do something on the

system. By executing the same command with the ppriv -e -D wrapper, more detailed information on

the missing privileges can be obtained.

oracle@ozone:~$ ppriv -eD ps

PID TTY TIME CMD

ps[2165]: missing privilege "proc_info" (euid = 501, syscall = 81) needed at pr_readdir_procdir+0x100

2165 pts/4 0:00 ps

2127 pts/4 0:00 bash

2118 pts/4 0:00 bash

ps[2165]: missing privilege "proc_info" (euid = 501, syscall = 81) needed at pr_readdir_procdir+0x100

Service Management

The Oracle Solaris Service Management Facility creates a supported, unified model for services and

service management on each Oracle Solaris system. A fundamental building block for system security,

the Oracle Solaris Service Management Facility ties together a number of technologies to accomplish

security goals, such as improving system and service availability, integrity assurance, resilience against

attacks, administrative authorizations, and auditing. As a diagnostic tool, it pinpoints core faults in

cascading failures in complex software architectures, reducing the problem of misdiagnosis.

A service usually is defined by a service manifest, an XML file that describes a service and any instances

associated with that service. The service manifest is pulled into the repository at boot time, or by using


14

the svccfg import subcommand. The Oracle database and the Oracle listener can be described in a

manifest. Each manifest specifies the dependencies that are prerequisites for the service to start, the

authorizations required to manage the service, and process credentials. In general, each service is

described in its own manifest file. However, multiple instances of the Oracle database can be described

in the same manifest. The example below names the Oracle database service, lists its dependencies, and

and names an instance (oowtest).

<service_bundle type="manifest" name="oracle-database-service">

<service name="application/oracle/database" type="service" version="0.2">

<dependency name="multi-user" grouping="require_all"

restart_on="error" type="service">

<service_fmri value="svc:/milestone/multi-user:default"/>

</dependency>

<instance name="oowtest" enabled="false">

Services can be started or stopped by the superuser and authorized users. These authorizations are

specific to each service and can be assigned to individual users or roles. The following example

specifies the authorizations required to temporarily or permanently start and stop an instance of the

Oracle database.

<property_group name="general" type="framework">



<propval name="action_authorization" type="astring"

value="solaris.smf.manage.oracle.database"/>



<propval name="value_authorization" type="astring"

value="solaris.smf.manage.oracle.database"/>

</property_group>

In the section on role-based access control, the oracle role was assigned the

solaris.smf.manage.oracle.database authorization. It is this authorization that allows the

oracle role to start and stop the oracle database via the Oracle Solaris Service Management Facility.

An authorized, but unprivileged user can start a service that requires specific process credentials (user,

group, and privileges). The example below specifies the credentials for the Oracle database. Note that

the credentials specified for this service do not enumerate any privileges beyond the basic set granted

to all users.

<method_credential

user="oracle"

group="oinstall"

limit_privileges=":default"

privileges="basic"

supp_groups=":default" />


15

The manifest also specifies the commands or scripts to execute when the service is started or stopped.

The example below shows the start and stop methods for the Oracle database.

</method_context>

<exec_method name="start" type="method"

exec="sh -c 'echo startup|$ORACLE_HOME/bin/sqlplus / as sysdba'"

timeout_seconds="500">

</exec_method>

<exec_method name="stop" type="method"

exec="sh -c 'echo shutdown immediate|$ORACLE_HOME/bin/sqlplus / as sysdba'"

timeout_seconds="900">

</exec_method>

<method_context/>

A significant feature the Oracle Solaris Service Management Facility is its ability to improve system and

service availability. The previous dependency specification includes the setting restart_on="error".

This setting instructs the Oracle Solaris Service Management Facility to restart the service if it

encounters a fatal error. While not a recommend procedure, a fatal error can be simulated by killing the

Oracle Service Monitor process and observing that the database service is restarted by the Oracle

Solaris Service Management Facility. The activity can be observed in real time by tailing the log file

associated with the service. The following command provides the pathname to the log file.

oracle@ozone:~$ svcs -l oracle/database:oowtest

The following command generates a fatal error.

oracle@ozone:~$ pkill -9 ora_smon

In can be observed in the log file that the Oracle Solaris Service Management Facility detects the failure

and restarts the service. The example below shows the normal command to stop the service.

oracle@zone:~$ svcadm disable oracle/database:oowtest

More information on writing a service manifest can be found at

http://hub.opensolaris.org/bin/view/Community+Group+smf/faq and

http://www.sun.com/bigadmin/content/selfheal/sdev_intro.jsp

Locking Down Oracle with Auditing

The Oracle Solaris audit feature provides the ability to log system activity at a granular level. System

activity refers to any auditable Oracle Solaris event, such as system calls on the server machine, packets

sent over the network, or a sequence of bits written to disk. As a result, the Oracle Solaris Containers

model offers an attractive environment for auditing. Processes that are run within the context of non-

global zones are separated and isolated from auditing software that is running in the global zone and

the kernel, while maintaining excellent visibility into its zones.


16

This type of monitoring hosted environments is often referred to as introspection. When the Oracle

Database runs in a non-global zone, it is possible to introspect the actions of the Oracle Database

administrator from the global zone.

Configuring the System for Audit

The first step in the process is to create the auditor role. As with the oracle role in the non-global

zone, it makes sense to delegate tasks to an auditor role in the global-zone. This allows different

actual users to assume the auditor role, as well as the auditing of the auditor.

Two rights profiles are pre-defined for reviewing and controlling the audit: Audit Review and Audit

Control. The example below creates a role that can review and control auditing on the system. These

activities can be separated into distinct roles. The following command defines the auditor role.

root@paris:~# roleadd -P "Audit Review,Audit Control" -m -d \

/export/home/auditor -s /usr/bin/bash auditor

root@paris:~# passwd auditor

In order for the auditor to read and write to the default location of the audit log, ownership of the

/var/audit directory must be changed.

root@paris:~# chown auditor:other /var/audit

The final step is to add the auditor role to one or more users.

root@paris:~# usermod -R auditor tstark

Determining What to Audit

Auditing control in Oracle Solaris is granular. Some upfront planning is required to determine which

events need to be recorded. The types of events that can be audited in Oracle Solaris are grouped into

classes. The classes are defined in the /etc/security/audit_class file. For example, configuring

the auditing of the fd class lets administrators audit every time a file is deleted.

no:invalid class

fr:file read

fw:file write

fa:file attribute access

fm:file attribute modify

fc:file create

fd:file delete

cl:file close

nt:network


17

ip:ipc

na:non-attribute

lo:login or logout

ap:application

ss:change system state

as:system-wide administration

ua:user administration

am:administrative (meta-class)

aa:audit utilization

ad:old administrative (meta-class)

ps:process start/stop

pm:process modify

pc:process (meta-class)

xp:X - privileged/administrative operations

xc:X - object create/destroy

xs:X - operations that always silently fail, if bad

xx:X - all X events (meta-class)

io:ioctl

ex:exec

ot:other

all:all classes (meta-class)

The system events that map to the audit classes are defined in the /etc/security/audit_event

file. Over 500 unique system events exist. A given event can map to one or more audit classes.

For a detailed discussion of planning, configuration, and management of the Oracle Solaris auditing

subsystem, See Part VII, Oracle Solaris Auditing of the System Administration Guide: Security Services located at

http://docs.sun.com/app/docs/doc/816-4557/audittm-1.

Configuring the Audit

Among other things, the classes to audit are configured in the etc/security/audit_control file.

The content of the default audit_control file is shown below.

dir:/var/audit

flags:

minfree:20

naflags:lo


18

In this file:

• dir defines where audit log files are written. Audit files can be written on the local machine or an

NFS mount to another server. The example below uses the /var/audit directory of the local

machine.

• flags specifies the classes to audit.

• minfree defines the percentage of free space required before the audit_warn script is invoked. See

the audit_warn(1M) man page for how to work with the audit_warn script.

• naflags stands for non-attributable flags. It is used to log audit events that cannot be attributed to a

specific user, such as commands that happen during the boot process.

The audit classes defined in the audit_control file record events for all users of the system. The

example below records the events of a specific role, oracle. A secondary file, audit_user, is used

for this purpose. The default audit_user file contains a single entry root:lo:no, that is defined as

follows.

username:always-audit-flags:never-audit-flags

The audit logs whenever the root user logs into or out of the system. The invalid class is never

audited — there are no classes excluded from auditing for this user. Remember, additional classes can

be defined in the audit_control file.

For the purposes of the example, add the following to the audit_user file.

# Always audited for logins, never for audit utilization

audit:lo:aa

# Always audited for login, user administration, system-wide administration

oracle:lo,ex,ua,as:no

Finally, be sure the audit log captures additional useful information, such as the arguments passed to

the commands and the zone from which the commands were run. To accomplish this, add the

following two lines to the /etc/security/audit_startup file.

/usr/sbin/auditconfig -setpolicy +argv

/usr/sbin/auditconfig -setpolicy +zonename

Securing the Audit

The audit_user file must exist in every zone to be audited. However, as an additional security

measure, administrators can loopback mount the file as read-only from the global zone to prevent the

local zone from potentially tampering with the type of audit data collected. It's also interesting to note

individual files as well as file systems can be added to a zone. Save the following to the

ozone_audit_cfg file.


19

add fs

set dir=/etc/security/audit_user

set special=/etc/security/audit_user

set type=lofs

set options=ro

end

verify

commit

Apply the zone configuration changes.

root@paris:~# zonecfg -z ozone -f ozone_audit_cfg

These configuration changes require the zone to be rebooted. Do not reboot the zone now. The entire

machine needs to be rebooted after auditing is enabled.

Enable Auditing

Switch to the auditor role. Run the /etc/security/bsmconv script to enable Oracle Solaris

auditing. Reboot the machine as instructed.

Viewing the Audit Log

On reboot, log into the zone ozone and execute commands, such as sqlplus.

root@paris:~# ssh -X jdoe@ozone

Password:

Last login: Wed Jun 16 11:26:02 2010 from 10.0.2.15

Sun Microsystems Inc. SunOS 5.10 Generic January 2005

jdoe@ozone:~$ su - oracle

Password:


You have new mail.

oracle@ozone:~$ . oraenv

ORACLE_SID = [oracle] ? ORCL

The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 is

/u01/app/oracle

oracle@ozone:~$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Wed Jun 16 11:26:43 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to an idle instance.

SQL>


20

Switch to the auditor role in the global zone. Recall that one of the commands assigned to the

auditor as part of the Audit Review was praudit, which prints the contents of the audit trail. As

configured, the audit records are written to the /var/audit file. File names correspond to the date of

the audit records.

auditor@paris:~$ ls /var/audit

20100617142549.20100617143516.paris

20100617143518.20100617143707.paris

20100617143724.not_terminated.paris

The not_terminated file is the open audit log that is being written. An audit log can be printed to

text as follows.

auditor@paris:~$ pfexec praudit /var/audit/20100617143724.not_terminated.paris > audit.txt

The record of the sqlplus command looks as follows.

header,203,2,execve(2),,paris,2010-06-17 10:37:54.764 -04:00

path,/u01/app/oracle/product/11.2.0/dbhome_1/bin/sqlplus

attribute,100751,501,501,65545,37367,18446744073709551615

exec_args,4,sqlplus,/,as,sysdba

subject,200,501,501,501,501,15301,1789246745,8929 71168 paris

return,success,0

zone,ozone

The file is more readable when presented as HTML. This can be accomplished by outputting the file as

XML and converting it to HTML.

auditor@paris:~$ pfexec praudit -x /var/audit/20100617143724.not_terminated.paris >

audit.xml

auditor@paris:~$ xsltproc audit.xml > audit.html

Audit records can be viewed with a Web browser, such as Firefox.


21

Figure 6. Audit records viewed in a Web browser

While the output is fairly self-explanatory, some discussion of the SUBJECT line is warranted. It lists

several user and group IDs. Each zone has its own namespace, and auditing does not know about

zone-scoped naming. If user ID 101 is assigned to jdoe in the local zone, and to tstark in the global

zone, the audit resolves 101 to tstark. This is why the example gave users and roles in the local zone

unique user and group ids. To get the audit log to show the actual user and group names instead of the

ids, create stub accounts in the global zone. It does not matter if the stub accounts are users or roles.

root@paris:~# roleadd -u 501 oracle

root@paris:~# useradd -u 200 jdoe

root@paris:~# groupadd -g 501 oinstall

When the audit logs are printed, the user and group IDs are more user friendly.

Figure 7. Audit log content viewed in a Web browser


22

When launching the Web browser from the auditor role, a DISPLAY error occurs. This is because

X11 forwarding is not carried forward when switching to a role.

auditor@paris:~$ firefox audit.html

Xlib: connection to ":0.0" refused by server

Xlib: No protocol specified

(firefox-bin:3952): Gtk-WARNING **: cannot open display:

The wrapper script below can be used to carry forward the X11 authority record when switching to the

auditor role.

tstark@paris:~$ cat sux

#!/bin/bash

if [ ! $1 ]; then

echo "Missing parameter user/role"

exit

fi

if [ ! $DISPLAY ]; then

echo "No DISPLAY variable set to forward"

exit

fi

PRE_AUTH="/usr/openwin/bin/xauth add $(/usr/openwin/bin/xauth list

${DISPLAY//*:/:})"

echo "The following record has been added to your X authorization file"

echo $PRE_AUTH

su - $1 -c "$PRE_AUTH;DISPLAY=$DISPLAY \$SHELL"

The wrapper script can be used as follows.

tstark@paris:~$ ./sux auditor

The following record has been added to your X authorization file

echo /usr/openwin/bin/xauth add paris/unix:0 MIT-MAGIC-COOKIE-1

cbfedbfde2d4dfc1c8c5f3dfe2dafbfd

Password:


/usr/openwin/bin/xauth: creating new authority file /export/home/auditor/.Xauthority


23

The sample script below produces the HTML version of the audit log and refreshes the file every 10

seconds. Just refresh the browser to see the new data.

pfexec praudit -x /var/audit/*not_term* > audit.xml

xsltproc audit.xml > audit.html

firefox audit.html &

while [ true ]; do

pfexec praudit -x /var/audit/*not_term* > audit.xml

xsltproc audit.xml > audit.html

sleep 10

done

Stopping and Starting the Audit

Auditing is under control of the Oracle Solaris Service Management Facility.

auditor@paris:~$ svcs -l auditd

fmri svc:/system/auditd:default

name Solaris audit daemon

enabled true

state online

next_state none

state_time Thu Jun 17 12:42:00 2010

logfile /var/svc/log/system-auditd:default.log

restarter svc:/system/svc/restarter:default

contract_id 381

dependency require_all/none svc:/system/filesystem/local (online)

dependency require_all/none svc:/milestone/name-services (online)

dependency require_all/none svc:/system/system-log (online)

There is an authorization restriction in Oracle Solaris 10 10/09 that disallows the auditor from

persisting changes to the service. However, the service can be temporarily stopped and started (until

the next reboot) as follows.

auditor@paris:~$ svcadm disable -t auditd


24

Conclusion

This technical white paper addresses four pillars of the Oracle Solaris security model that enable

organizations to run Oracle Database services in a more secure manner: containment, least privilege,

service management and accountability. The recommendations made here can be implemented in

whole or in part as applicable in individual organizations.

• Containment. Containment is implemented using Oracle Solaris Containers, an operating system

virtualization technology. Within containers, zones have a unique IP address and are accessed just

like a physical machine. However, processes running in the zone have restricted privileges. For

example, processes in zones are not allowed to load kernel modules or access processes running in

other zones (other than through traditional networking protocols).

• Least privilege. Least privilege is implemented using role-based access control and Oracle Solaris

privileges. Role-based access control is used to define specific roles within the organization, assign

just the privileges needed to perform those roles (least privilege), and assign those roles to actual

system users. Oracle Solaris privileges apply the same concept to running processes — they have the

minimum set of privileges needed to accomplish tasks.

• Service management. Service management is implemented using the Oracle Solaris Service

Management Facility. This tool enables the customization of which privileges are assigned to running

processes. For example, even though the oracle role may have a limited set of privileges, processes

started by the oracle role can have a greater (or more restricted) set of privileges.

• Accountability. Accountability is implemented using auditing. Auditing allows administrators to

configure the events that are recorded. A history of which event occurred — when and by whom —

is logged. A combination of role-based access control and auditing allows the determination of not

only which role performed the action, but also the user behind the role. In contrast, using a

traditional user account for the oracle role would always leave open the question of which actual

user performed the action.

References

[1] Sun Microsystems Engineers, Solaris 10 Security Essentials, Prentice Hall, 2010.

[2] G. Faden, Authorization Infrastructure in Solaris, Oracle Sun Developer Network (SDN), 2001.

[3] D. Ferraiolo and K. D.R., “Role-Based Access Control”, Proceedings of the 15th National Computer

Security Conference (NCSC), 1992.

[4] H. J. F. Foxwell, M. Lageman, J. Pronk van Hoogeveen, I. Rozenfeld, S. Setty, and J. Victor, The

Sun BluePrints Guide to Solaris Containers - Virtualization in the Solaris Operating System, Sun BluePrints

Online, (Part No 820-0001), October 2006.

[5] Authorization description database man page, auth_attr(4).


25

[6] Oracle Solaris application containers man page, brands(5).

[7] Change root directory for a command man page, chroot(1M).

[8] ipkg branded zone man page, ipkg(5).

[9] Change login password and password attributes man page, passwd(4).

[10] Administer a new role account man page, roleadd(1M).

[11] Extended user attributes database man page, user_attr(4).

[12] Execution profiles database man page, exec_attr(4).

[13] Profile description database man page, prof_attr(4).

[14] Administer zones man page, zoneadm(1M).

[15] Best Practices for Running Oracle Databases in Solaris Containers,

http://wikis.sun.com/display/BluePrints/Best+Practices+for+Running+Oracle+Databases+in+Solar

is+Containers

[16] Using Oracle Solaris 10 to Overcome Security Challenges,

http://www.oracle.com/technetwork/articles/servers-storage-admin/index.html

[17] SecurityAdvantages of the Solaris Zones Software,

http://wikis.sun.com/display/BluePrints/Security+Advantages+of+the+Solaris+Zones+Software

[18] Trent Jaeger, Operating System Security, Morgan & Claypool Publishers, ISBN 9781598292121.

[19] Restricting Service Administration in the Solaris 10 Operating System,

http://wikis.sun.com/display/BluePrints/Restricting+Service+Administration+in+the+Solaris+10+

Operating+System

[20] Limiting Service Privileges in the Solaris 10 Operating System,

http://wikis.sun.com/display/BluePrints/Limiting+Service+Privileges+in+the+Solaris+10+Operatin

g+System

[21] Understanding the Security Capabilities of Solaris Zones Software,

http://hub.opensolaris.org/bin/download/Project+isc/WebHome/820%2D7017.pdf

Hardening Oracle Database with Oracle Solaris

Security Technologies

August 2010

Author: Glenn Faden, Brian Leonard, Christoph

Schuba

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

This document is provided for information purposes only and the contents hereof are subject to change without notice.

This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed

orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose.

We specifically disclaim any liability with respect to this document and no contractual obligations are formed either

directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any

means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their

respective owners.

AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro

Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are

used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered

trademark licensed through X/Open Company, Ltd. 0310

Documents

Hardening Oracle Database with Oracle Solaris Security ... · Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies 1 Introduction This white paper