RE: Lockdown database privs question
- From: "Freeman CTR Donald" <donald.freeman.ctr@xxxxxxxx>
- To: <Lisa.Koivu@xxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 20 May 2013 14:55:11 -0400
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Koivu, Lisa
Sent: Monday, May 20, 2013 14:46
To: oracle-l@xxxxxxxxxxxxx
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.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
