![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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. For details on prerequisites, refer to the "TAMOS Installation Guide," which is linked to in the Resources section at the end 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:
install_amos_platform, where 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
./install_amos_linux.
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. Again, you can refer to the "TAMOS Installation Guide," which is linked to in the Resources section at the end of this article, for detailed installation instructions.
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 subscribessuffix— user registry suffix under which users associated with TAMOS are createdregistry_ssl_cacert— certificate of TAM user registry serveradmin_name— the name of the Tivoli Access Manager administratoradmin_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 |
For detailed configuration instructions, refer to the "TAMOS Administration Guide," which is linked to in the Resources section at the end of this article.
Setting up authorization policies
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.
The following example demonstrates how you can use TAMOS access controls to protect against fraudulent behavior:
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.
Following is the syntax to create an object:
Object create /OSSEAL/<Server name>/Resource "Description" <object type> ispolicyattachable yes|no
So, for example, in the case described above, you could use a command like the one in Listing 2 to create an object for the surrogate resource.
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.
This section demonstrates how TAMOS can help you deal with two real-world issues faced by DB2 customers.
Some DB2 customers have reported experiencing an instance crash due to a SIGKILL (kill -9)
signal being sent to the db2sysc process.
When a kill -9 signal is sent to db2sysc,
a DB2 instance crash is the expected behavior.
However, the instance crash of a production system can have a significant business impact.
The example described in this section illustrates this type of scenario.
Assume that you have a DB2 instance named db2ins95.
To begin the scenario, issue a
ps command, as shown in Listing 6, to list the DB2 processes for
your db2ins95 instance.
Listing 6. List DB2 instance processes
[db2ins95@Server ~]$ ps -ef | grep db2 root 7970 7929 0 12:32 pts/2 00:00:00 su - db2ins95 db2ins95 7971 7970 0 12:32 pts/2 00:00:00 -bash db2ins95 8380 1 0 12:39 pts/2 00:00:00 /home/db2ins95/sqllib/bin/db2bp 7971A2077 5 A root 8587 1 0 12:45 pts/2 00:00:00 db2wdog 0 db2ins95 8588 8587 0 12:45 pts/2 00:00:00 db2sysc 0 root 8589 8588 0 12:45 pts/2 00:00:00 db2ckpwd 0 root 8590 8588 0 12:45 pts/2 00:00:00 db2ckpwd 0 root 8591 8588 0 12:45 pts/2 00:00:00 db2ckpwd 0 root 8592 8588 0 12:45 pts/2 00:00:00 db2pmd 0 db2ins95 8593 8588 0 12:45 pts/2 00:00:00 db2gds 0 db2ins95 8594 8588 0 12:45 pts/2 00:00:00 db2licc 0 db2ins95 8595 8588 0 12:45 pts/2 00:00:00 db2ipccm 0 db2ins95 8596 8588 0 12:45 pts/2 00:00:00 db2resync 0 db2ins95 8598 8588 1 12:45 pts/2 00:00:00 db2acd 0 ,0,0,0,1,0,0,0,897d44 ,14,1e014,2,0,1,11fd0,0x11f90000,0x11f90000,1610000,100004,2,478009 db2ins95 8617 7971 0 12:45 pts/2 00:00:00 ps -ef db2ins95 8618 7971 0 12:45 pts/2 00:00:00 grep db2 root 14366 1 0 Mar19 ? 00:00:25 /opt/ibm/db2/V9.1/bin/db2fmcd |
Next, connect users to SAMPLE database, as shown in Listing 7.
Listing 7. Connect users to SAMPLE database
[db2ins95@Server ~]$ db2 "connect to sample" Database Connection Information Database server = DB2/LINUX 9.1.5 SQL authorization ID = DB2INS95 Local database alias = SAMPLE [db2ins95@Server ~]$ db2 list tables Table/View Schema Type Creation time ------------------------------- --------------- ----- -------------------------- ACT DB2INS95 T 2010-03-22-12.37.09.890866 ADEFUSR DB2INS95 S 2010-03-22-12.37.13.858864 CL_SCHED DB2INS95 T 2010-03-22-12.37.09.641766 DEPARTMENT DB2INS95 T 2010-03-22-12.37.09.654181 DEPT DB2INS95 A 2010-03-22-12.37.09.716163 EMP DB2INS95 A 2010-03-22-12.37.09.749817 EMPACT DB2INS95 A 2010-03-22-12.37.09.887997 EMPLOYEE DB2INS95 T 2010-03-22-12.37.09.717494 EMPMDC DB2INS95 T 2010-03-22-12.37.15.079208 EMPPROJACT DB2INS95 T 2010-03-22-12.37.09.876485 |
Listing 8 shows kill -9 being issued against the db2sysc process
and the DB2 instance crashing.
Listing 8.
kill -9 against db2sysc causes instance
crash[db2ins95@Server ~]$ kill -9 8588 [db2ins95@Server ~]$ db2 list tables SQL1224N The database manager is not able to accept new requests, has terminated all requests in progress, or has terminated your particular request due to a problem with your request. SQLSTATE=55032 [db2ins95@Server ~]$ db2 connect to SAMPLE SQL1032N No start database manager command was issued. SQLSTATE=57019 |
Listing 9 is an example of the resulting entries in the db2diag.log file after the instance crash.
These entries indicate that the instance crash occurred due to SIGKILL
being issued by a user or application.
Listing 9. Sample db2diag.log entries
2010-03-22-12.49.14.993973-300 I39299G722 LEVEL: Error PID : 8587 TID : 3086112448 PROC : db2wdog 0 0 INSTANCE: db2ins95 NODE : 000 FUNCTION: DB2 UDB, oper system services, sqlossig, probe:10 MESSAGE : Sending SIGKILL to the following process id DATA #1 : signed integer, 4 bytes -8588 CALLSTCK: [0] 0x0276568D sqlossig + 0x117 [1] 0x0132313A sqloWatchDogMain + 0x20E [2] 0x0132192A sqloRunInstance + 0xCE [3] 0x0804D450 DB2main + 0x6DC [4] 0x0804CD6C main + 0x24 [5] 0x04938DF3 __libc_start_main + 0xD3 [6] 0x0804CCB1 _Z21sqlePdbProcessRequestP11sqkfChannelPv + 0x1C1 [7] 0x00000000 ?unknown + 0x0 [8] 0x00000000 ?unknown + 0x0 [9] 0x00000000 ?unknown + 0x0 |
Now you will see how TAMOS can help you prevent the scenario described above.
First, create an object for the db2sysc process as a file
resource in the TAMOS object space,
as shown in Listing 10.
Listing 10. Create object
pdadmin sec_master> object create /OSSEAL/Server.in.ibm.com/File/home/db2ins95\ /sqllib/adm/db2sysc "Db2 process" 3 ispolicyattachable yes |
Next, as shown in Listing 11, create a policy that does not give DB2 instance user db2ins95 and root user permission to kill the process.
Listing 11. Create policy
pdadmin sec_master> acl create db2-acl pdadmin sec_master> acl modify db2-acl set user root T[OSSEAL] pdadmin sec_master> acl modify db2-acl set user db2ins95 T[OSSEAL] |
Now the ACL is defined not to give DB2 instance user db2ins95 and root user the kill (that is, the "k") permission bit. The last step is to enforce the policy on the object, as shown in Listing 12.
Listing 12. Enforce the policy on the object
pdadmin sec_master> acl attach /OSSEAL/Server.in.ibm.com/File/home/db2ins95\ /sqllib/adm/db2sysc db2-acl |
Issue the ps command again to list the DB2 processes that are running.
Compare the sample output in Listing 13 to that in Listing 6.
Listing 13. List DB2 instance processes
[db2ins95@Server root]$ ps -ef | grep db2 root 14366 1 0 Mar19 ? 00:00:29 /opt/ibm/db2/V9.1/bin/db2fmcd root 28330 28278 0 23:42 pts/1 00:00:00 su db2ins95 db2ins95 28331 28330 0 23:42 pts/1 00:00:00 bash root 28426 1 0 23:42 pts/1 00:00:00 db2wdog 0 db2ins95 28427 28426 0 23:42 pts/1 00:00:00 db2sysc 0 root 28428 28427 0 23:42 pts/1 00:00:00 db2ckpwd 0 root 28429 28427 0 23:42 pts/1 00:00:00 db2ckpwd 0 root 28430 28427 0 23:42 pts/1 00:00:00 db2ckpwd 0 root 28431 28427 0 23:42 pts/1 00:00:00 db2pmd 0 db2ins95 28432 28427 0 23:42 pts/1 00:00:00 db2gds 0 db2ins95 28433 28427 0 23:42 pts/1 00:00:00 db2licc 0 db2ins95 28434 28427 0 23:42 pts/1 00:00:00 db2ipccm 0 db2ins95 28435 28427 0 23:42 pts/1 00:00:00 db2resync 0 db2ins95 28437 28427 0 23:42 pts/1 00:00:00 db2acd 0 ,0,0,0,1,0,0,0,897d44 ,14,1e014,2,0,1,11fd0,0x11f90000,0x11f90000,1610000,130003,2,590009 db2ins95 28629 28434 0 23:47 pts/1 00:00:00 db2agent (idle) 0 db2ins95 28951 28331 0 23:52 pts/1 00:00:00 ps -ef db2ins95 28952 28331 0 23:52 pts/1 00:00:00 grep db2 |
Now, as shown in Listing 14,
when the db2ins95 or root user tries to kill the db2sysc process,
he is not allowed to do so because you have used TAMOS to put the
proper controls and policies in place.
Listing 14. kill -9 not permitted
[db2ins95@Server root]$ kill -9 28427 bash: kill: (28427) - Operation not permitted |
TAMOS can also help you track who actually issued the kill command, which can lead to you identifying the real culprit. This tracking functionality is discussed later in the article.
DB2 support has also documented several problem reports where a customer has accidentally deleted tablespace containers while performing operating system maintenance activities. In some cases, this has resulted in the loss of a significant amount of data. This type of scenario also results in the tablespace becoming inaccessible. The example described in this section illustrates this type of scenario.
As in Case 1, for this example assume that you have a DB2 instance named db2ins95.
To begin the scenario, connect users to SAMPLE database, as shown in Listing 15.
Listing 15. Connect users to SAMPLE database
[db2ins95@Server root]$ db2 "connect to sample" Database Connection Information |
As shown in Listing 16, create a tablespace with one container named cont1.
Listing 16. Create a tablespace
[db2ins95@Server root]$ db2 "create tablespace tbsp1 managed by database \ using (file '/test/cont1' 1000)" DB20000I The SQL command completed successfully. |
Create a table named table1 in the cont1 tablespace, as shown in Listing 17.
Listing 17. Create tables
[db2ins95@Server root]$ db2 "create table table1(id int, name varchar(10)) in tbsp1" DB20000I The SQL command completed successfully. |
Then, as shown in Listing 18, insert some sample data into the table.
Listing 18. Insert sample data
db2ins95@Server root]$ db2 "insert into table1 values(1,'a'),(2,'b'),(3,'c')"
DB20000I The SQL command completed successfully.
[db2ins95@Server root]$ db2 "select * from table1"
ID NAME
----------- ----------
1 a
2 b
3 c
3 record(s) selected.
[db2ins95@Server test]$ db2 connect reset
DB20000I The SQL command completed successfully.
|
To simulate what would happen if the tablespace were accidentally deleted,
issue an rm command, as shown in
Listing 19.
Listing 19. Delete the tablespace container
[root@Server ~]# rm -rf /test/cont1 |
Now, as shown in Listing 20, when users reconnect to the database and try to access the table, they receive an error.
Listing 20. Access attempt returns error
[db2ins95@Server test]$ db2 connect to sample Database Connection Information Database server = DB2/LINUX 9.1.5 SQL authorization ID = DB2INS95 Local database alias = SAMPLE [db2ins95@Server test]$ db2 "select * from table1" ID NAME ----------- ---------- SQL0290N Table space access is not allowed. SQLSTATE=55039 |
The tablespace has become inaccessible because its container was deleted, and all the data you inserted in the table is lost!
Now you will see how TAMOS can help you in the type of situation outlined above by preventing users from removing the containers, and thereby securing your system against potential data loss.
In this example, the container, which is simply a file resource on the operating system, is in the /test directory. As shown in Listing 21, create an object for /test/cont1 under the file resource.
Listing 21. Create an object
pdadmin sec_master> object create /OSSEAL/Server.in.ibm.com/File/test/cont1 \
"Containers" 2 ispolicyattachable yes
|
Next, create a policy to protect against users being able to remove this object, as shown in Listing 22.
Listing 22. Create a policy
pdadmin sec_master> acl create cont-acl
pdadmin sec_master> acl modify cont-acl set user root T[OSSEAL]rwx
pdadmin sec_master> acl show cont-acl
ACL Name: cont-acl
Description:
Entries:
User sec_master TcmdbsvaBRl
User root T[OSSEAL]rwx
|
Now, the ACL is defined to give the root user read, write, and execute permissions, but not the deletion (that is, the "d") permission bit. The last step is to enforce the policy on the object, as shown in Listing 23.
Listing 23. Enforce the policy on the object
pdadmin sec_master> acl attach /OSSEAL/Server.in.ibm.com/File/test/cont1 cont-acl |
Now, as shown in Listing 24, when the root user tries to remove the container, he is not allowed to do so. TAMOS has just prevented accidental data loss due to deletion of the container.
Listing 24. Container deletion not permitted
[root@Server ~]# rm -rf /test/cont1 rm: cannot remove `/test/cont1': Permission denied |
This section describes how you can use TAMOS to monitor or track operations performed against DB2 processes and resources.
For example,
in the scenario described in Case 1 above,
a kill -9 was issued against the db2sysc process.
If such a situation were to actually occur, you would likely want to know who was
responsible for the action.
The fine and granular level of auditing provided by TAMOS can help you do so.
TAMOS provides three levels of auditing:
- User
- Resource
- Global
The following example illustrates resource level auditing. Assume that as described in Case 1, the policies shown in Listing 25 are in place for your system.
Listing 25. Case 1 policies
pdadmin sec_master> object show /OSSEAL/Server.in.ibm.com/File/home/db2ins95\
/sqllib/adm/db2sysc
Name: /OSSEAL/Server.in.ibm.com/File/home/db2ins95/sqllib/adm/db2sysc
Description:
Type: 3 (Executable)
Is Policy Attachable: Yes
Extended Attributes:
Attached ACL: db2-acl
Attached POP:
Attached AuthzRule:
Effective Extended Attributes:
Effective ACL: db2-acl
Effective POP:
Effective AuthzRule:
|
With the above policies,
the ACL db2-acl protects the db2sysc from being killed.
Now, as shown in Listing 26, create a POP with a specification that all actions on the
protected object will be audited.
This tells TAMOS to track when
a SIGKILL is issued against the resource
regardless of whether or not the user is allowed to kill the db2sysc process.
Listing 26. Create a POP to audit all actions
pdadmin sec_master> pop create track-user pdadmin sec_master> pop modify track-user set audit-level all |
Enforce the policy on the object by attaching the POP to the object, as shown in Listing 27.
Listing 27. Enforce the policy on the object
pdadmin sec_master> pop attach /OSSEAL/Server.in.ibm.com/File/home/db2ins95\ /sqllib/adm/db2sysc track-user |
Issue the ps command to list the DB2 processes that are
running, as shown in Listing 28.
Listing 28. List DB2 instance processes
[db2ins95@Server root]$ ps -ef | grep db2 root 14366 1 0 Mar19 ? 00:00:33 /opt/ibm/db2/V9.1/bin/db2fmcd root 19969 18669 0 11:59 pts/2 00:00:00 su db2ins95 db2ins95 19970 19969 0 11:59 pts/2 00:00:00 bash db2ins95 20051 19970 0 11:59 pts/2 00:00:00 ps -ef db2ins95 20052 19970 0 11:59 pts/2 00:00:00 grep db2 db2ins95 29476 1 0 00:05 ? 00:00:00 /home/db2ins95/sqllib/bin/db2bp 29389A2077 root 30183 1 0 00:14 ? 00:00:00 db2wdog 0 db2ins95 30184 30183 0 00:14 ? 00:00:00 db2sysc 0 root 30185 30184 0 00:14 ? 00:00:00 db2ckpwd 0 root 30186 30184 0 00:14 ? 00:00:00 db2ckpwd 0 root 30187 30184 0 00:14 ? 00:00:00 db2ckpwd 0 |
Now, as shown in Listing 29, a user attempts to kill the db2sysc process,
but the operation is not permitted.
Listing 29.
kill -9 not permitted[db2ins95@Server root]$ kill -9 30184 bash: kill: (30184) - Operation not permitted |
Listing 30 is an example of the resulting entries in the audit.log file after the
attempt to issue the kill -9.
Although the user was not allowed to kill the process, the action is tracked and does not go unnoticed.
You could also use the
pdosaudview utility provided by TAMOS to view the audit
report.
Listing 30. Snapshot from the audit.log
*** START OF NEW RECORD *** Timestamp Tue 23 Mar 2010 11:59:25 AM EST Audit Event An authorization decision was made. Audit View Deny Audit Reason Resource Audit Audit Resource Type File Accessor Name root Accessor Effective Name db2ins95 Audit Action Check Access Audit Permissions kill Audit Qualifier Checking resource access control policy. Policy Branch Name Server.in.ibm.com Protected Object Name File/home/db2ins95/sqllib/adm/db2sysc System Resource Name /home/db2ins95/sqllib/adm/db2sysc Accessor Process ID 19970 Running Program System Resource Name /bin/bash Audit Outcome Success Audit Uniqifier 0 |
The above record shows that a kill was issued against the
system resource, /home/db2ins95/sqllib/adm/db2sysc.
The Accessor Effective field shows that the user who issued the
kill was db2ins95.
This article introduced you to the IBM Tivoli Access Manager for Operating Systems (TAMOS) solution. It provided an overview of how you can install and configure TAMOS, and showed how it can be used to protect DB2 processes and resources on UNIX and Linux operating systems. Once you understand the concepts of TAMOS, you will be in a better position to provide security to your system resources on top of that provided by the native operating system.
Learn
- The
"TAMOS Installation Guide"
contains detailed instructions for installing and configuring TAMOS 6.0 on various
platforms.
-
The
"TAMOS
Administration Guide",
contains information on TAMOS-protected resources and policies.
- The
DB2 Infocenter
describes how to use DB2 and its features.
-
The
Auditing UNIX/Linux System Use with
Tivoli Access Manager for Operating
Systems and Tivoli Compliance Insight
Manager Redpaper provides details on
auditing Linux and UNIX systems with TAMOS.
Discuss
- Participate in the discussion forum.
- Check out
developerWorks
blogs and
get involved in the
developerWorks community.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
