Let’s begin by setting the scene. There is a new db created with the RESTRICTIVE clause. The user who created the db was DB2LEARN (DB2LEARN holds SYSADM authority). DB2LEARN granted some authorities on the database.
$ db2 "create role ckure"
(A new ROLE, named CKURE...that’s probably a clue, care to make a guess what happens next? )
$ db2 "grant secadm on database to role ckure"
(You were right...CKURE is a ROLE for SECADMs.)
$ db2 grant connect on database to user secauth
$ db2 "grant role ckure to user secauth"
(Ok...so SECAUTH is going to be a SECADM on this database)
Obviously one way to check the results of these commands is to query the appropriate SYSCAT views (DBAUTH and ROLEAUTH). But, this post is about DB2LOOK, so let’s get back to that. We know that authority to run DB2LOOK is held by SYSADM and SYSCTRL. We also know that DB2LOOK, when run with the -x option,
db2look -d dbname -x -o myfilename
generates authorization statements and writes (outputs) them to a text file. There are MANY reasons we would want to be cognizant about security when it comes to SYSADM, SYSCTL, and SYSMAINT operations, but for this example we will just deal with this one. So, let’s take a “look” at db2look:
$ db2look -d lockem -x -o lockem.auth.out
$ cat lockem.auth.out
----------------------------------------
-- Authorization Statements on Database
----------------------------------------
GRANT SECADM ON DATABASE TO ROLE "CKURE " ;
GRANT CONNECT ON DATABASE TO USER "SECAUTH " ;
---------------------------------------
-- Authorization Statements for Roles
---------------------------------------
GRANT ROLE "CKURE " TO USER "SECAUTH " ;
Wow...that’s good stuff. I can see who holds CONNECT authority, who the SECADM is and can even tell that any user who is granted the ROLE named CKURE will have SECADM authority. Obviously, this is information we want to keep “in house”. On my machine at the moment, it’s sitting on an unencrypted disk drive. Perhaps that is not a good plan. I’m afraid that leaving little “clues” around like this might just give someone some evil ideas.
It this was a “real” database and not just one that I’m using to play locksmith, I’d be really concerned. The good thing is that db2look can only be run by someone with SYSADM or SYSCTL authority. Given the “power” the SYSADM, SYSMAINT and SYSCTRL authorities have, I will want to audit those events anyway. At least db2audit will capture an audit event for any execution of DB2LOOK. But, I don’t think that’s enough. I’d probably also create a written policy that states that when db2look is run, the information has to be secured (this could be accomplished in a variety of ways, email me if you want suggestions). But, as we all know, policies do not always lead to 100% compliance. So, auditing and additional steps to secure the output are probably a very good idea.
I WELCOME YOUR EMAILS TO:
db2locksmith at securedb2.com