hardening oracle database with oracle solaris security ... · oracle white paper—hardening oracle...
TRANSCRIPT
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!
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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,...
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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,
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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 5160 1305 0 14:56:12 ? 0:01 ora_arc0_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 5164 1305 0 14:56:14 ? 0:01 ora_arc2_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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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">
<!-- start and stop oracle -->
<propval name="action_authorization" type="astring"
value="solaris.smf.manage.oracle.database"/>
<!-- make persistent changes across reboots -->
<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" />
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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:
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
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>
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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.
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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:
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
/usr/openwin/bin/xauth: creating new authority file /export/home/auditor/.Xauthority
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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).
Oracle White Paper—Hardening Oracle Database with Oracle Solaris Security Technologies
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