|
简短回答是： 您不需要。您可以通过发出以下命令删除不需要的权限： $ chmod 4700 $ORACLE_HOME/bin/oracle
执行该命令后，权限将和下面的类似。 -rws------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle
现在我们可以通过 SUID 位转到策略。 在本例中，SUID 位设置为 ON（通过所有者的 rws 权限指示）。 策略
由于您不需要除 Oracle 软件所有者（本例为“orasoft”）之外的任何用户的权限来运行 Oracle 可执行文件，因此应该从可执行文件中删除 SUID 位，使其仅供所有者访问，其他任何人都不可访问。 $ chmod 0700 $ORACLE_HOME/bin/oracle
权限现在看起来与下面的类似： -rwx------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle
结论
这是较大的改动，理解其影响很重要。 当服务器上的用户（非 Oracle 软件所有者）尝试连接一个本地连接时，可执行文件“oracle”将以该用户的名义运行，就好像用户“orasoft”正在运行该文件一样。 这很重要；因为服务器进程将打开“orasoft”拥有的数据文件，该进程必须以“orasoft”身份运行，或者用户必须具有打开数据文件的权限。
例如，假设 UNIX 用户“ananda”登录到数据库所在的服务器，并进行本地连接： $ sqlplus arup/arup
该用户将立即收到一条错误信息。 ERROR:
ORA-12546: TNS:permission denied
Enter user-name:
原因很简单： 您删除了文件“oracle”上的 SUID 权限。 当用户执行本地连接时，实质上是尝试运行可执行文件“oracle”，但是由于 SUID 未设置，因此不会以用户“orasoft”身份尝试而是以“ananda”身份尝试。 由于用户 ananda 没有运行该文件的权限，因此该文件也不会得到执行，因此出现了 ORA-12546 错误。
那么，ananda 怎样才能连接数据库呢？ 有两种方法。 一个方法是，使所有用户进程在数据库服务器本身之外的服务器上运行，如此就不会存在到数据库的 bequeath 连接，只有非 LOCAL 连接。 因为非 LOCAL 连接经过监听程序进程，监听程序为其衍生了服务器进程，所以服务器进程的所有者是“orasoft”（Oracle 软件所有者），而不是运行客户端进程的用户。 没有需要发布的权限。
或者，如果必须在数据库服务器本身上运行某些用户进程，您可以使用以下命令通过监听程序连接 $ sqlplus arup/arup@dba102
这与从服务器外部连接的用户具有同样的效果。 现在，只有拥有 Oracle 软件的用户（本例为 orasoft）可以通过 bequeath 连接来连接到数据库。
具有单独的操作系统 ID 的 DBA 将不能使用命令 connect / as sysdba 来关闭或启动数据库，即使他们属于 dba 组。 他们可以通过以下命令执行该操作 $ sqlplus /nolog
SQL> connect sys/Password_of_SYS@dba102 as sysdba
是的，该方法使用了 SYS 密码；但是无论如何，与 / as sysdba 相比，该方法要好些。 但是，一种更好的方法是为各个 DBA 创建 Oracle 用户 ID： connect ANANDA/Password_of_ANANDA@dba102 as sysdba
黑客惯用的伎俩是使用任意帐户登录服务器，然后尝试强行进入数据库。 （典型的“松散门户”是用户“nobody”。） 即使黑客没有进入数据库，他也可以通过 oracle 可执行文件的缓冲区溢出创建拒绝服务攻击。 如果删除了执行该文件的功能，那么该攻击的效果将受到严格限制。 同时，正如所见，您没有删除合法用户的任何功能。 总之，大多数用户使用监听程序连接到数据库，而且并不会受到太大影响。
操作计划
准备
查看系统上是否有任何用户构建了 bequeath 连接。 为此，您可以执行以下操作：
- 通过询问
- 在服务器上搜索进程，查看是否有象 SQL*Plus 一样明显的内容
- 查看 V$SESSION 的 MACHINE 列
select program
from v$session
where machine = '<machine_name>';
如果出现一些这样的内容，您可以通过打开审计（在后续阶段将学习该功能）并捕获来自该服务器的所有程序来识别运行的确切程序。 操作
| IF 没有程序连接到服务器，THEN |
| |
更改 oracle 可执行文件的权限
chmod 0700 $ORACLE_HOME/oracle |
| ELSIF 某些程序从服务器进行连接 |
| |
将连接从 UserID/Password 更改为 UserID/Password@Connect_String |
END IF
IF 您频繁从 shell 脚本作为 sqlplus / as sysdba 进行连接 THEN |
| |
将其更改为使用 DBAUser/Password@Connect_String |
| END IF |
1.3 保护其他可执行文件
背景
看看 $ORACLE_HOME/bin 目录中的其他可执行文件；有些看起来很熟悉，例如 sqlplus 或 lsnrctl（启动监听程序的实用工具）；有些您可能并不熟悉。
其中一些文件（例如监听程序进程运行的实用工具 tnslsnr 或在 Oracle Intelligent Agent 中使用的 dbsnmp）最终用户不会直接接触到。 要正确保护这些文件，您必须了解它们的作用，从而采取相应的措施。
请记住，如果为文件设置了 SUID 位，则无论哪个用户运行该文件，该文件都在所有者的权限下运行，而不是在执行者的权限下运行。 您还应清楚，设置 SUID 是一种危险行为，不应给予鼓励。
还有一些文件将 SUID 设置为 on。 让我们将它们找出来。 $ cd $ORACLE_HOME
$ find . -type f \( -perm -2000 -o -perm -4000 \) -exec ls -l {} \;
在 Oracle 数据库 10g 第 1 版和更高版本中，上述命令应仅返回以下可执行文件： -rwsr-s--x 1 orasoft dba 93300507 Jul 22 11:20 ./bin/oracleO
-r-sr-s--- 1 root dba 0 Jul 1 23:15 ./bin/oradism
-rwsr-s--x 1 orasoft dba 94492 Jul 22 11:22 ./bin/emtgtctl2
-rwsr-s--- 1 root dba 18944 Jul 22 11:22 ./bin/nmb
-rwsr-s--- 1 root dba 20110 Jul 22 11:22 ./bin/nmo
-r-sr-sr-x 1 nobody nobody 58302 Jul 22 11:23 ./bin/extjob
(编辑:aniston)
|
