DB2 LUW Security -- A New SECADM in Town


Posted by bond on November 22, 2009, 6:40 pm
in General ( DB2 Security)

There’s a New SECADM in Town. It's a new day and there is a new database. Which means a new chance for me to set up security.....and this time....I’m taking control icon_exclaim
There’s a New SECADM in Town. It's a new day and there is a new database. Which means a new chance for me to set up security.....and this time....I’m taking control.

The FACTS:

A new database DB2LEARN has been created by the user DB2INST1 in the instance DB2INST1


$ db2 get instance


The current database manager instance is: DB2INST1


$ db2 "get dbm cfg" | grep -i sysadm


SYSADM group name (SYSADM_GROUP) = DB2INST1


My ID is SECBOSS. A fitting ID, don't you think? Let's connect to the DB2LEARN database and begin our security investgation.


$ db2 connect to db2learn user secboss


According to documentation, the SYSADM that created the database should have SECADM authority on the newly created database, DB2LEARN, by default. Let's check that theory out.



$ db2 "select char(grantor,35) as grantor, char(grantee,35) as grantee from syscat.dbauth where securityadmauth='Y'"


GRANTOR GRANTEE


SYSIBM DB2INST1


DB2INST1 SECBOSS

Notice the GRANTOR of SECADM to DB2INST1 is SYSIBM. So, it appears the documentation is correct and that this was done by default


But we also discover that the instance owner, DB2INST1, has already granted the user SECBOSS (that's me) SECADM authority on the DB2LEARN database. There are now two SECADM authorities granted on the DB2LEARN database. I don't want to share the fun with others, but I think I know how to fix this.


My First TASK:


In keeping with the Security Concept, “Separation of Duties”, SECBOSS will revoke SECADM database authority from DB2INST1, so that it NO LONGER holds SECADM Authority on the database. I still have my connection to the DB2LEARN database and I am connected with my id, SECBOSS, so I think ALL I have to do is....

$ db2 revoke secadm on database from DB2INST1

Wow. That was easy. Did it work?


$ db2 "select char(grantor,35) as grantor, char(grantee,35) as grantee from syscat.dbauth where securityadmauth='Y'"


GRANTOR GRANTEE


DB2INST1 SECBOSS



Sweet. SECBOSS now is the only SECADM on the DB2LEARN database. Now that we have banished the DB2INST1 guy, we have the control we need to start setting up security. This is going to be fun! I hope there is a pay increase involved. I should check on that before I do anything else. Wonder which shoes I should wear to ask for a raise? Shoe shopping research is next on the agenda.


If y’all want to help with my shoe research or discuss DB2 Security (either or both) I would welcome your emails.





I got an EXCELLENT question on this post and thought I'd share the answer here:

Q: is SECBOSS now the SECADM for the database or the instance?


A: SECBOSS was granted SECADM (a database authority) on the database. If a new database was created by DB2INST1 in the same DB2INST1 instance, the default SECADM for the NEW db would still be DB2INST1. The SECBOSS would NOT have SECADM on the NEW db in the DB2INST1 instance by default.


One more comment. Although I have used DB2INST1 in this example, I would NOT use DB2INST1 as an instance id in real life. Using Well Known IDs is not a good idea unless you're just trying to give hackers a helping hand.



I WELCOME YOUR EMAILS TO:
db2locksmith at securedb2.com




Post from : http://www.dbisoftware.com/blog/db2_security.php
Printed from : http://www.dbisoftware.com/blog/db2_security.php?id=154