oracle的公共权限

确保Oracle数据库安全的技术原则之一，就是仔细分析有关用户组PUBLIC的使用情况。用户组PUBLIC，顾名思义，表示数据库中的每一位用户，因此，对PUBLIC用户组授予权限其实也就是对数据库中的每一位用户都授予了相应的权限。这是在授予或撤销权限时非常有用的一条捷径。但也可能带来巨大的安全隐患，尤其是在试图确保以最少权限的方式运行数据库时，更是如此。

2.5.1 何时给PUBLIC组授予权限

在很多时候，给PUBLIC授予权限是比较切合实际的，并且不会产生安全隐患。例如，绝大部分的Oracle数据库应用开发人员都知道DUAL表非常有用，而且绝对不含有敏感信息。对于很多其他过程和函数来说，情况也是如此—— SYSDATE函数就是一个很好的例子，它很有用也不会产生安全隐患。因此，PUBLIC组访问DUAL表和SYSDATE函数不会带来安全风险。

遗憾的是，很难知道给PUBLIC授予权限是不是真的会带来安全风险。当在开发应用时，需要谨慎地决定给PUBLIC授予什么样的权限—— 如果需要授予权限的话。

同时也需要了解有些在目前不会带来风险，却有可能会在将来带来风险的问题。例如，假设在一个Web应用中，有一张表存储用户的选择项。初始时，允许用户在表中保存他们在制作个人主页时所使用的背景颜色、前景颜色以及字体类型。这些信息都不属于敏感信息，因此，可以被任何用户查看。

scott@KNOX10g> CREATE TABLE user_prefs

2 (background_color VARCHAR2(6),

3 foreground_color VARCHAR2(6),

4 font_style VARCHAR2(20));

 

Table created.

 

scott@KNOX10g> GRANT SELECT ON user_prefs TO PUBLIC;

 

Grant succeeded.

 

 

后来，可能需要在该表中添加一项敏感的属性，例如，允许用户在表中存储所喜欢的主页和应用的超链接。

scott@KNOX10g> ALTER TABLE user_prefs ADD favorite_links VARCHAR2(250);

 

Table altered.

在添加属性之后，将会完全改变表的敏感性。而授予PUBLIC组的权限也应该被撤销。管理PUBLIC组权限的安全准则为：只要不确定是否安全，就不要给PUBLIC授予权限。

2.5.2 Oracle 支持的对象

为了有效地确保Oracle数据库的安全，需要考虑开发的或购买的应用以及Oracle数据库对象已经给PUBLIC授予的权限。

需要仔细考虑由两个Oracle对象默认授予PUBLIC的权限问题：

● 对数据字典视图的访问 有些数据字典的视图会泄露用户的信息，从而可以被利用发起针对数据库的攻击。

● 对过程的执行 这包括PL/SQL函数、程序、包以及Java程序。这些过程能执行很多有用的函数—— 例如打开网络连接、从运行的系统中读取文件、设置有关用户或应用的认证信息—— 所有以上过程都可以被用在稍后将要介绍的数据库安全处理过程中，例如访问控制和审计。

1. PUBLIC组对字典视图的访问

通过限制对敏感数据的访问，Oracle数据库提供了对数据库字典元数据的安全保护措施。随着时间的推移，对“敏感数据”的定义已经有了若干发展：初始时，敏感数据指的是加密的用户密码之类的表项；现在，甚至是数据库的用户名也被看作是敏感数据。然而，PUBLIC组仍然可以访问其中的部分数据。

例如，ALL_USERS视图可以被PUBLIC组访问，而且其中列出了每一个数据库模式的用户名。黑客们经常使用的一招就是获取并利用合法的用户账号试图访问其他的账号。数据库权限选择模式(MDYS)、默认的应用账号以及用户的账号都会被ALL_USERS视图列出，而这正成为了恶意用户最有效的目标。合法的数据库用户成为了针对数据库的有效攻击目标！而且，恶意用户很容易就会说：“噢！看啊！数据库中安装了<insert option name or your application here>选项。让我使用默认的密码试着访问这个被授权的账号看看！”

因此，应该考虑撤销PUBLIC组对某些数据库元数据访问的权限。而利用ALL作为SYS对象名称的前缀则是不错的主意：

SELECT table_name

FROM dba_tab_privs

WHERE grantee = 'PUBLIC'

AND owner = 'SYS'

AND PRIVILEGE = 'SELECT'

AND table_name LIKE 'ALL%';

2. 受损的对象

在撤销PUBLIC组对默认数据库对象访问权限的时候，还应该了解在撤销的同时可能会损害哪些当前已存在的程序或应用。下面的例子显示了当撤销PUBLIC对ALL_USERS视图的访问权限后，有20个数据库对象变得无效：

sys@KNOX10g> SELECT count(*) FROM all_objects

2 WHERE status = 'INVALID';

 

COUNT(*)

----------

0

 

1 row selected.

 

sys@KNOX10g> REVOKE SELECT ON all_users FROM PUBLIC;

 

Revoke succeeded.

 

sys@KNOX10g> SELECT count(*) FROM all_objects

2 WHERE status = 'INVALID';

 

COUNT(*)

----------

20

 

1 row selected.

损害并不是不可修复的。如果某个应用依赖于曾经授予PUBLIC组的某个权限，那么可以直接给这个应用授予相应的权限从而进行修复工作。对于数据字典视图，下面列出了需要直接授予权限的模式：

sys@KNOX10g> -- Show whose objects are broken.

sys@KNOX10g> SELECT distinct owner

2 FROM all_objects

3 WHERE status = 'INVALID';

 

OWNER

--------------------

DMSYS

EXFSYS

LBACSYS

SYS

SYSMAN

XDB

 

6 rows selected.

在上述模式中，部分模式拥有系统权限SELECT ANY DICTIONARY，通过该权限可以访问ALL_USERS视图。这些模式中的部分对象将会在没有授予任何权限的情况下重新编译；而其他一些模式则需要直接被授予有关ALL_USERS视图的权限。通过使用如下代码中黑体部分的SQL函数可以列出仍然需要被直接授予相关权限的模式。这段代码的运行结果将列出需要被直接授予相关权限的模式：

sys@KNOX10g> -- create list of users who require

sys@KNOX10g> -- direct select privileges on ALL_USERS

sys@KNOX10g> SELECT DISTINCT 'grant select on all_users to '

2 || owner

3 || ';' sql_command

4 FROM (SELECT DISTINCT owner

5 FROM all_objects

6 WHERE status =

7 'INVALID'

8 AND owner != 'SYS'

9 MINUS

10 SELECT grantee

11 FROM dba_sys_privs

12 WHERE PRIVILEGE =

13 'SELECT ANY DICTIONARY');

 

SQL_COMMAND

------------------------------------------------------------

grant select on all_users to DMSYS;

grant select on all_users to EXFSYS;

grant select on all_users to LBACSYS;

grant select on all_users to XDB;

 

4 rows selected.

在SQL_COMMAND的值中利用复制和粘贴方法，可以给需要授权的用户直接授予相应的权限。当授权后，这些模式中的无效对象需要被重新编译。

遗憾的是，几乎不可能对撤销权限的后果进行预测，这也就是Oracle为什么还没有撤销PUBLIC的有关数据库元数据视图的权限。而在Oracle Database Security Guide中也警告说撤销PUBLIC的DML权限并不是一件很简单的事：

撤销PUBLIC的权限可能会引起一连串的影响。如果从PUBLIC中撤销任何有关DML操作的权限，那么数据库中的所有过程，包括函数和包，在被使用之前都必须重新认证。因此在给PUBLIC授予或撤销与DML相关的权限时需要格外小心。

3. 程序中的PUBLIC权限

下面分析程序中授予PUBLIC的执行权限。再次说明：不能在此列出更多的程序，而且这些程序经常会有变化。而在确保之前所介绍的视图中的程序的安全时也面临同样的问题。但是，知道有哪些程序能完成哪些功能对于理解其安全风险是非常重要的—— 如果存在安全风险的话。

最值得关注的是那些以DBMS%和UTL%开始的程序：

SELECT table_name

FROM dba_tab_privs

WHERE grantee = 'PUBLIC'

AND owner = 'SYS'

AND PRIVILEGE = 'EXECUTE'

AND table_name LIKE 'DBMS%'

OR table_name LIKE 'UTL%'

ORDER BY 1;

警告：

对于这些程序或SYS的对象，不要吝啬您的评估。数据库中的所有对象和应用都应该被评估。

在Oracle Database Security Guide中建议撤销PUBLIC的有关UTL_SMTP、UTL_TCP、UTL_HTTP以及UTL_FILE的执行权限。而我们不仅仅只是撤销上述这些执行权限，还应该记住这些执行权限限制了对应用、用户以及对象的访问。

正如上述的元数据示例，经常有应用依赖于授予这些程序的PUBLIC权限。而为了成功地删除这些权限，不仅需要理解其依赖关系，还需要解决在撤销权限过程中所出现的任何问题。第6章提供了关于撤销DBMS_SESSION包的执行权限的示例。