PUBLIC

[BeatrixKiddo]

Looking at the list got from SELECT * FROM SYS.DBA_TAB_PRIVS found lots of tables to which PUBLIC has granted access, like ALL_* for example, but also SESSION_ROLES, SYSTEM_PRIVILEGE_MAP and many others.

Which should be considered to revoke? I guess not all of them but are there any PUBLIC mustn't have access?

 

[SantaMufasa]

Beatrix,

The decision about which privileges to grant to PUBLIC is one that should be driven by your organization's security policy. If your organization does not have a security policy that governs Oracle privilege allocations, then that is a bigger issue than the one you post here. You need guidance from your management's IT Policy and Procedures personnel.

Once you receive that guidance, you then can issue appropriate 'REVOKE <privilege> FROM PUBLIC;" to the inappropriate privileges.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
“Beware of those that seek to protect you from harm or risk. The cost will be your freedoms and your liberty.”

 

[BeatrixKiddo]

Certanly they don't have it (an internal policy), that is why I need a kind of "best practices" list to consider, have been able to get one.

 

[SantaMufasa]

Actually, Beatrix, in most organizations, it is fully appropriate for all users to have full SELECT access to the list of "ALL_*" views. Here is some background...there are four major groups of data dictionary classifications, by prefix:

[ul][li]USER_*: the objects that the current, logged-in user owns.[/li][li]ALL_*: the objects to which the current, logged-in user has access. This prefix is a bit misleading since the list does not show ALL objects, simply the ones to which the current user has access. (A better prefix for this group would have been "ACCESSIBLE_*".[/li][li]DBA_*: this group of objects truly show ALL objects in the database. The only users that have default access to these data dictionary views are those that have been granted the "DBA" role.[/li][li]V$: these views are very similar to the "DBA_*" views in that they contain information that is typically available to DBAs only. These views are labelled "V$..." in that they are "virtual" views that are populated only while the database instance is "up and running".[/li][/ul]I doubt that you will find any of the "DBA_*" or "V$*" views have been granted to PUBLIC. Any of the "ALL_*" views that are granted to PUBLIC are totally reasonable since everyone should be able to see the objects to which they have been GRANTed access.


I hope that this overview gives you some confidence in evaluating your current situation. If not, we invite you to post those questions.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
“Beware of those that seek to protect you from harm or risk. The cost will be your freedoms and your liberty.”

 

[karluk]

The Oracle security administration guide recommends revoking execute privileges from the following system packages: utl_file, utl_http, utl_smtp, utl_tcp, dbms_lob, dbms_job and dbms_random. We have adhered to this recommendation in all of our Oracle databases. In addition, one of our customers has additional security in place which requires us to remove public execute on dbms_debug and dbms_stats, as well as public select on all_users. I wasn't part of the decision making process for that customer, so I don't know the specifics of why those permissions were revoked.

Naturally, all of these permissions can be granted to individual ids or roles based on need. The idea is simply not to give the permissions by default to everyone.

Oracle also recommends password protecting the listener (very important!) and disabling and locking unused system accounts. All of these things should be a routine part of your database creation procedures. Then you won't have to remember to do them after the fact.

The following link is a short and fairly good overview to some of the basic things you should be doing to secure your Oracle databases. Perhaps you can use it as a start to putting together a "best practices" policy.

http://www.oracle-base.com/articles/misc/BasicSecurityMeasuresForOracle.php