RE: Lockdown database privs question
Date: Mon, 20 May 2013 14:55:11 -0400
Message-ID: <01A5BB2CD1A5394C894C7D94EE4E6E49023BD354_at_mcusquanez28v.mcdsus.mcds.usmc.mil>
I encountered problems trying to do this. In order to be compliant I had to "remove unused features." I did. I now have a lot of invalid objects in various schemas that won't compile because there are hooks into other Oracle modules that are no longer there. I also did the "revoke from public" thing which even Grid Control identifies as a critical policy alert. After I did that the patches and cpu's started failing. Oracle has a lot of code that doesn't explicitly reference objects for which they have granted permissions to public.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Koivu, Lisa
Sent: Monday, May 20, 2013 14:46
To: oracle-l_at_freelists.org
Subject: Lockdown database privs question
Hello all,
11.2.0.3, Solaris 10, Enterprise Edition
I am working through database and executable privileges in a default Oracle install, and molding it into a PCI-compliant install.
Our chosen standard is the CIS 11g standard, v1.1. As you know, the default install and freshly created database is very liberal with privileges. Lots of perceived unnecessary read and execute grants to public, excessive permissions within the executable, etc. as well as conflicting items within the standard. It is impossible to be 100% compliant.
The 10g install I completed a few years ago is locked down in every way possible. I boldly changed permissions within the executable directory, yanked public permissions within the database and the end result was a compliant database within which the application operates without issue.
I have questioned Oracle Support and Oracle expert friends about the feasibility of doing this in 11g. The general consensus is DO NOT CHANGE PERMISSIONS, future patches and upgrades may depend upon these loose privileges. However, I look in the database and see default items such as:
- execute on DBMS_OBFUSCATION_TOOLKIT is granted to PUBLIC
- Delete on FGA_AUD$ and AUD$ is granted to DELETE_CATALOG_ROLE
- Many select grants on DBA* views to PUBLIC
- Select on ALL_SOURCE to PUBLIC
Honestly this makes me ill.
How many of you have encountered this? If so, how did you handle it? Is comp-controlling a large number of items within a database and executable standard practice? Call me paranoid but that does not give me a warm fuzzy, these items are on the standard for a reason. Yes, the db is behind multiple firewalls and it would be an enormous pain to even get to the host, and then decrypt triple-encrypted data. However, the perfectionist in me wants this done *right*.
It is worth noting that patches are tested prior to production implementation (the perfectionist in me again) - patch install/deinstall, dataguard switchover functionality testing with the app, etc. If a patch didn't work I would know prior to prod implementation, but Oracle Support indicated if it appears to be a permissions issue, we will recommend a reinstall.
Thoughts, comments, ideas, stories, flame wars, all are welcome. My instinct is to butcher the privileges, limit comp-controlling, and be prepared if one day it goes sideways during a patch/upgrade. I don't think you can be too safe.
Thank you for any insight you are willing to provide.
Lisa Koivu
database administrator
Starwood vacation ownership
orlando, fl
UNITED STATES Always be willing to accept a temporary inconvenience for a permanent improvement. - H. Jackson Brown, Jr.
This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" field.
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Mon May 20 2013 - 20:55:11 CEST