Securing the DBMS

Although this next step might sound a bit draconian, it's a good step to take for fresh installs: revoke PUBLIC access from everything. This way you have a clean canvas to work with. A good, usable system should operate on the principle of least privilege. This essentially means that only those permissions that are required to do a job should be given. Once PUBLIC has been taken out of the equation, it's far easier to do this. Please note that it's not possible to revoke PUBLIC access from absolutely everything. It's not possible to revoke PUBLIC execute access on procedures and functions in the SYSIBM and SYSFUN schemas. This is a real shame and hopefully will one day change because it tends to be things like routines that suffer from vulnerabilities such as buffer overflows. For everything that can be revoked, though, it should be. I've tested this on my system and it all seems to work okay, but again, before doing this on your production systems you should fully test it on your development systems. (If you do find there are problems, remember they could be solved by directly assigning access to specific accounts or groups — it'll be worth the effort, so persevere!)

To revoke PUBLIC access on objects, use the Control Center. Select the database in question and navigate to User and Group Objects. Under this, select DB Groups. In the right-hand pane, double-click PUBLIC. The Database tab should be presented. This lists authorities assigned to PUBLIC. Uncheck all ...

Get The Database Hacker's Handbook: Defending Database Servers now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.