There are times when something just gets “stuck” in my brain and won’t let me go. I'm sure we all have those moments. Mine typically center around security or shoes or both. They come without any concrete facts and they pop up when I am not expecting them, but sometimes they can help solve a puzzle or direct you to the solution that you didn’t even realize you needed. I’ve accidentally solved a lot of DB2 problems thanks to those unexpected moments. Let me share the story of one of the times that something just "clicked" in my security brain and see if you and I can work through this together to see if it “could” be a DB2 Security concern.
While working through an upgrade of some security programs that I had written, I had an opportunity to repeatedly see the result set as I iteratively worked out the inevitable bugs. I kept seeing the DBM DIAGLEVEL pop up in my output results. I think it was only there because I hadn’t filtered it out when I wrote my program originally…lazy coding no doubt.
My mind, however, just would not let go of the DIAGLEVEL and whether there could be any security threat involved with that particular parameter. Since my mind latched on to that thought, I knew I would replay the question in my mind for hours. For me these types of mental queries are much like those of someone who can’t get an annoying song out of their head. I was not looking forward to the looping replay I knew my brain would insist on singing to me.
So, I gave in, and truly started thinking about it. In DB2 9.7, the parameter can be changed online without an instance bounce, but it can only be updated by someone holding SYSADM authority. The online part sounded like a clue since it’s an easy change, but given few users hold SYSADM, it seemed to even out.
However there was one scenario that came to mind. What if there was an internal employee who wanted to do the most damage before the inevitable pink slip? What if that person held SYSADM? How would they use something as seemingly innocuous as the diaglevel to their advantage? Does anyone actually even look at the diaglevel unless something is broken? And, at that moment, this thought came to mind…if you want to deliberately break things, you disable the troubleshooting ability to the greatest extent possible because you don’t want it fixed. Setting the diaglevel to zero to turn off all DB2DIAG.LOG diagnostic capturing would make sense in that scenario.
What do you all think? Is that a plausible scenario for making the DIAGLEVEL a DBM CFG parameter of interest to the DB2 Security Professional?
Oh, if you want an easy SQL script to run and gather some security information (including the value of the DBM CFG DIAGLEVEL), check out the DB2Night Show # 5 on Thursday, November 12.