DB2 LUW Security -- A New SECADM in Town

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