标准Linux安全中的setuid程序

 

2.2.3.标准Linux安全中的setuid程序

在我们讨论如何处理域转变的问题之前，首先看一下类似的问题在标准Linux中是如何处理的，即Joe想安全地修改现有的密码问题，Linux解决这个问题的方法是通过给passwd赋一个setuid值，使其执行时具有root权限，如果你在一个普通Linux系统上列出密码文件，你看到的会是：

# ls -l /usr/bin/passwd -r-sxx  1 root root 19336 Sep  7 04:11 /usr/bin/passwd

这里注意两件事，第一个是在所有者权限的x位置被设置为s了，这就是所谓的setuid位，意思是任何执行这个文件的进程，它的有效UID（即用户ID）将会被改为文件所有者。这里，root是文件所有者，因此当执行密码程序时实际上将会以root用户的ID运行，图2-4显示了这些步骤。

（点击查看大图）图2-4.标准Linux中密码程序安全（setuid）

当Joe运行密码程序时真正会发生的是他的shell将会产生一个fork()系统调用创建一个它自身的副本，这个复制进程仍然有真实有效的用户ID（joe），并且仍然运行有shell程序（bash）。然而，在调用完fork指令后，新的进程将会产生一个execve()系统调用来执行密码程序。标准Linux安全需要调用的用户ID（仍然是joe）有x权限，这里确实就是这样，因为所有人都有x权限。成功执行execve()调用将会发生两件非常关键的事情，第一件是运行在新进程中的shell程序将会被passwd程序替换，第二，因为setuid位是为所有者设的，真正的用户ID将从进程的原始ID改为文件所有者的ID（这里是root），因为root可以访问所有文件，那么密码程序也就可以访问shadow密码文件了，也就可以处理Joe修改密码的需求了。

setuid位的使用在类Unix操作系统中非常普遍，这是它们的一个简单但强大的特性，然而，它也成为标准Linux安全的主要弱点，密码程序需要以root身份运行访问shadow文件，然而，当以root身份运行时，密码程序可以访问所有的系统资源，这就违背了中心安全工程的最小权限原则，结果，我们必须信任密码程序，对于信任的安全应用程序，密码程序需要一个扩展的代码审核来确保它不会滥用它的特权，而且，当遇到无法预见的错误时，会影响到密码程序，这样就可能会将缺陷引入，即使密码程序相当简单且是高度受信任的，想象一下其他程序（包括登陆shell）可能以root身份运行将会是多么可怕的。

我们真正要做的事情应该是确保为密码程序设置最小权限，我们认为密码程序应该只能访问shadow文件和其他与密码有关的文件，再加上那些必须的最小系统资源，同时我们还应该确保除了密码程序能访问shadow文件外，其他程序都不能访问这个文件，这样说来，我们就只需要关心密码程序它自身的角色就行了，不用管用户账号了