Secure DB2 resources using Tivoli Access Manager for Operating Systems

Learn how to secure your IBM® DB2® resources using Tivoli® Access Manager for Operating Systems (TAMOS). TAMOS is an IBM solution for securing resources on UNIX® and Linux® operating systems. This article steps you through two real-world scenarios to show you how to use TAMOS to set policies that protect DB2 resources. You can use these scenarios as a foundation for building an enterprise-wide security solution for your database.

Aditi Prasad (aditiprasad@in.ibm.com), Associate Software Engineer, IBM

Aditi Prasad photoAditi Prasad is an Associate Software Engineer. She currently works with Tivoli Security Products at IBM India Software Lab, Pune.



Nishant Sinha (nishant_sinha@in.ibm.com), DB2 Advanced Technical Support Analyst, IBM

Sinha Nishant photoNishant Sinha is a DB2 advanced technical support analyst at IBM India Software Lab, Pune His main focus is assisting IBM DB2 customers worldwide.



22 April 2010

Also available in Portuguese

Introduction

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

What is TAMOS?

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
file open > open mapped to pdos_open > TAMOS calls authorization > Is permitted? > if yes, real open and file descriptor; if no, denied

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.

Installation

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
Welcome screen of the InstallShield Wizard for TAMOS
Figure 3. Recommended System Settings
System check shows current memory, required memory, space requirements, and whether operating system is at supported level

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.

Configuring TAMOS

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

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.

Policy database

In a Tivoli Access Manager (TAM) environment, a policy database stores the ACLs and POPs defined on an object.

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.


Real-world scenarios

This section demonstrates how TAMOS can help you deal with two real-world issues faced by DB2 customers.

Case 1

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

TAMOS steps in!

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.

Case 2

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!

TAMOS steps in!

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

Auditing and tracing

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.


Conclusion

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.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management, Tivoli
ArticleID=484137
ArticleTitle=Secure DB2 resources using Tivoli Access Manager for Operating Systems
publish-date=04222010