Every database management system must be able to protect data against unauthorized access and modification. This also holds true for IBM DB2 Database for Linux, UNIX, and Windows® (DB2). DB2 uses several mechanisms, such as authentications, authorizations, and privileges, to meet this need. However, to protect its resources (such as processes, containers, system files), DB2 mostly relies on the native operating system.
Tivoli Access Manager for Operating System (TAMOS) is an IBM solution that uses a centralized policy management approach to protect resources on UNIX or Linux operating systems. Therefore, you can use it to provide an extra layer of security in addition to that provided by the native operating system.
Following is an overview of the topics covered by the article:
- Introduction of TAMOS along with an overview of how to install and configure
- How to use authorization policies to protect DB2 resources
- Real-world scenarios that throw light on potential security loopholes of the database management system as well as the native operating system on which it is installed, and how you can use TAMOS to close those loopholes
- How to track and monitor the operations against DB2 processes
The UNIX and Linux operating systems pose several security concerns from an enterprise perspective. TAMOS addresses these concerns by providing operating system-level access control for UNIX and Linux operating systems. The TAMOS centralized policy management technique prevents unauthorized access, and monitors accesses to sensitive data and resources.
TAMOS is implemented as a series of daemons, kernel extensions, and control files for either the UNIX or Linux operating system. The TAMOS kernel extensions intercept all the system calls. The centralized authorization daemon named
pdosd then participates in all authorization decisions when a system call is made.
The flow chart in Figure 1 demonstrates how TAMOS implements the security layer by intercepting the system calls at the kernel level.
Figure 1. Sample flowchart to illustrate TAMOS kernel interception
There are several prerequisite system requirements that must be met before you can begin to install and configure IBM TAMOS. However, a detailed description of these prerequisites is beyond the scope of this article.
You can install TAMOS in one of four ways:
- Multiplatform GUI-mode installation
- Multiplatform console-mode installation
- Multiplatform silent mode installation
- Native installation
The example in this section describes the first type of installation — how to perform a GUI mode installation of TAMOS, and specifically on a Linux server. The examples in later sections of the article also assume use of the Linux operating system.
To begin an interactive GUI-mode installation, locate your TAMOS CD and run the program with the name:
platform represents the name of your operating system. This program begins the installation process by launching the installation wizard. For the example installation on a Linux system described in this article, the install program is
Figures 2 and 3 show sample screenshots from the TAMOS installation wizard.
Figure 2. Tamos Installation screen
Figure 3. Recommended System Settings
As you proceed through the wizard, it guides you through the installation and configuration of TAM Runtime, using the appropriate LDAP server.
The silent mode of installation uses response files to install silently. The native installation uses the native software installation utility provided by the operating system.
This section explains how to configure TAMOS on a UNIX or Linux operating system after you perform a native installation. When you use Installshield multiplatform to install, TAMOS is already configured as part of the installation process. However, if you perform a native installation, you still need to configure TAMOS after the installation.
The command you use to configure TAMOS after a native installation is
pdoscfg. Following are the required configuration options that you must specify with your initial configuration:
branch— policy branch to which this system subscribes
suffix— user registry suffix under which users associated with TAMOS are created
registry_ssl_cacert— certificate of TAM user registry server
admin_name— the name of the Tivoli Access Manager administrator
admin_pwd— the password for the Tivoli Access Manager administrator
Listing 1. Sample command for configuration of TAMOS
[root@Server~]#pdoscfg -registry_ssl_cacert /ldapcert.arm -branch Server.in.ibm.com \ -suffix o=ibm,c=in -admin_name administrator -admin_pwd password
The term DB2 resources refers to DB2 processes, containers, system files, etc. that are present on the operating system where DB2 is installed. TAMOS uses various access controls such as Access Control Lists (ACLs) and Protected Object Policies (POPs) to protect these resources. It uses the static mode of creating objects in a policy database to protect them. Every DB2 resource that has to be protected must be explicitly created as an object in the policy database and must have an ACL/POP attached to it.
A root user who has all permissions on a UNIX or Linux machine tries to switch his identity to a DB2 instance user (for example, db2ins95) and tamper with some DB2 processes. This is where TAMOS would step in to provide protection. TAMOS provides a way you can protect surrogate operations by using surrogate resources. You start by creating an object.
Listing 2. Sample command for creating an object
pdadmin sec_master> object create /OSSEAL/Server.in.ibm.com/Surrogate/User/db2ins95 \ "SurrogateUser" 0 ispolicyattachable yes
You could then use a command like the one in Listing 3 to create a policy to prohibit root from switching user identity to db2ins95.
Listing 3. Sample command for creating an ACL
pdadmin sec_master> acl show surr-acl ACL Name: surr-acl Description: Entries: User sec_master TcmdbsvaBRl User root T
The above ACL shows the root user is not given the surrogate permission bit "G". Now you can use a command like the one in Listing 4 to attach the policy to the object for enforcement.
Listing 4. Sample command for attaching a policy to an object for enforcement
pdadmin sec_master> acl attach /OSSEAL/Server.in.ibm.com/Surrogate/User/db2ins95 surr-acl
Now, as shown in Listing 5, if the root user tries to change identity to a DB2 instance user, he is not allowed to do so.
Listing 5. Identity change to DB2 instance user not allowed
[root@Server ~]# whoami root [root@Server ~]# su - db2ins95 su: cannot set user id: Operation not permitted
The example in this section has shown you how to create objects and apply policies to them. Specifically, it showed you how to protect DB2 resources by controlling whether a root user can switch to a DB2 instance user. This ability to control root account use is one of the key features of TAMOS.