SET-UID程序漏洞实验

2.1 猜测为什么“passwd”，“chsh”，“su”，和“sudo”命令需要Set-UID机制，如果它们没有这些机制的话，会发生什么，如果你不熟悉这些程序，你可以通话阅读使用手册来熟悉它们，如果你拷贝这些命令到自己的目录下，这些程序就不会是Set-UID程序，运行这些拷贝的程序，观察将会发生什么。

从上面的截图可以看出：将passwd拷贝到/tmp/下，权限发生了变化（在原目录下suid位被设置），复件没有了修改密码的权限。

对于“chsh”，“su”，和“sudo”命令，把这些程序拷贝到用户目录下，同样不再具有root权限。

2.2.1 以root方式登录，拷贝/bin/zsh 到/tmp, 同时设置拷贝到tmp目录下的zsh为set-uid root权限，然后以普通用户登录，运行/tmp/zsh。你会得到root权限吗？请描述你的结果。

2.3 从上面步骤可以看出，/bin/bash有某种内在的保护机制可以阻止Set-UID机制的滥用。为了能够体验这种内在的保护机制出现之前的情形，我们打算使用另外一种shell程序——/bin/zsh。在一些linux的发行版中（比如Redora和Ubuntu），/bin/sh实际上是/bin/bash的符号链接。为了使用zsh，我们需要把/bin/sh链接到/bin/zsh。

下面的指令将会把默认的shell指向zsh：

$sudo su
Password:
#cd /bin
#rm sh
#ln -s zsh sh

2.4.1 你能够设置这个Set-UID程序运行你自己的代码而不是/bin/ls吗？如果你能的话，你的代码具有root权限吗？描述并解释你的观察。

普通用户运行test文件可以获得root权限

2.4.2 修改/bin/sh使得其返回到/bin/bash，重复上面的攻击，你仍然可以获得root权限吗？描述并解释你的观察。

修改sh连接回bash，运行test程序不能使普通用户获得root权限。

2.6.2 把myprog编译成一个Set-UID root的程序在普通用户下运行

在这种情况下，忽略LD_PRELOAD环境变量，不重载sleep函数，使用系统自带的sleep函数：

 

2.6.3 把myprog编译成一个Set-UID root的程序在root下运行

在这种情况下，使用LD_PRELOAD环境变量，使用重载的sleep函数：

 

2.6.4在一个普通用户下把myprog编译成一个Set-UID 普通用户的程序在另一个普通用户下运行

在这种情况下，不会重载sleep函数：

2.7 消除和清理特权

 

如图所示文件被修改了，原因在于设置uid前，zzz文件就已经被打开了。只要将语句setuid(getuid())移至调用open函数之前，就能避免这个问题。