Fork me on GitHub

深入理解SetUID

在Linux系统中每个普通用户都可以更改自己的密码,这是合理的设置。问题是:用户的信息保存在文件/etc/passwd中,用户的密码保存在文件/etc/shadow中,也就是说用户更改自己密码时是修改了/etc/shadow文件中的加密密码,但是,LOOK——
-rw-r--r-- 1 root root 1787 Oct 27  2009 /etc/passwd
-r-------- 1 root root 1187 Oct 27  2009 /etc/shadow
/etc/passwd文件每个用户都有读权限但是只有root有写权限,/etc/shadow文件只有超级用户root有读写权限,也就是说普通用户对这两个文件都没有写权限无法写入新密码,为什么普通用户可以更改密码呢?
PS:在Linux中设置或更改用户密码,是先写入到/etc/passwd文件然后通过pwconv命令转换到/etc/shadow文件,执行pwunconv命令可观察到转换前效果,会观察到/etc/shadow文件神奇的消失掉了,而/etc/passwd文件中原来打xx的地方变成了真正的加密密码。
 
其实,用户能更改密码真正的秘密不在于文件的权限,而在于更改密码的命令passwd 。
-rwsr-xr-x 1 root root 22960 Jul 17  2006 /usr/bin/passwd
passwd命令有一个特殊的权限标记s ,存在于文件所有者的权限位上。这是一类特殊的权限SetUID ,可以这样来理解它:当一个具有执行权限的文件设置SetUID权限后,用户执行这个文件时将以文件所有者的身份执行。passwd命令具有SetUID权限,所有者为root(Linux中的命令默认所有者都是root),也就是说当普通用户使用passwd更改自己密码的时候,那一瞬间突然灵魂附体了,实际在以passwd命令所有者root的身份在执行,root当然可以将密码写入/etc/shadow文件(不要忘记root这个家伙是superuser什么事都可以干),命令执行完成后该身份也随之消失。
 
可以试验用root身份修改passwd命令权限去掉SetUID :
chmod u-s /usr/bin/passwd
再尝试以普通用户身份登录后修改密码,就会发现提示:
passwd
Changing password for user samlee.
Changing password for samlee
(current) UNIX password:
passwd: Authentication token manipulation error
普通用户无法修改密码,所以只要能够想明白为什么普通用户可以更改密码就可以大概了解SetUID权限的作用。
 
接下来我们用两个SetUID的按理来进一步诠释下它的概念——
 
案例一:SetUID授权示例
 
为便于深入理解SetUID ,笔者以touch命令为例做一演示。
普通用户samlee用touch创建文件newfile01 :
touch newfile01
ls -l newfile01
-rw-rw-r-- 1 samlee samlee 0 05-21 01:20 newfile01
文件的创建者默认就是所有者,所以文件newfile01的所有者为samlee 。
管理员root给touch命令添加SetUID权限:
chmod u+s /bin/touch   # 或 chmod 4755 /bin/touch
ls -l /bin/touch
-rwsr-xr-x 1 root root 42284 Jul 13  2009 /bin/touch
再用普通用户samlee创建文件newfile02,看到如下结果:
touch newfile02
ls -l newfile02
-rw-rw-r-- 1 root samlee 0 05-21 01:48 newfile02
通过这个例子,我们可以再诠释下SetUID的定义,当一个可执行文件(命令touch)设置SetUID权限后,当普通用户samlee执行touch创建新文件时,实际上是以touch命令所有者root的身份在执行此操作,既然是以root身份执行,当然新建文件的所有者为root ,这就是SetUID的作用。
 
再看一下与SetUID类似的SetGID权限,看一个例子,给touch命令再授予SetGID :
chmod g+s /bin/touch   # 或 chmod 6755 /bin/touch
ls -l /bin/touch
-rwsr-sr-x 1 root root 42284 Jul 13  2009 /bin/touch
此时,再使用touch创建新文件newfile03,会看到如下现象:
touch newfile03
ls -l newfile03
-rw-rw-r-- 1 root root 0 05-21 01:48 newfile02
新建文件的所属组为touch命令的所属组,而不是执行touch命令的普通用户samlee的所属组,这就是SetGID的作用,与SetUID类似,用户在执行具有SetGID的命令时会调用命令所属组的身份。
 
案例二:危险的SetUID
 
对于SetUID的使用,可以做一个的比喻:一个绝密机关,要让一些人进来做一些事情,但是不能让他们看见机关内部的情况,于是授权一些特殊的“车辆”(没有窗户,车门紧闭,看不到外面,只有一个小洞允许乘坐的人伸出手臂做事),带着所乘坐的人开到要去的地方,允许它办完事情马上带他出来。这样是不是很安全?不一定。如果 “车辆”没有经过精挑细选,可能有很多“门窗”,那可就危险了,这种类似的场景相信大家在一些警匪电影中已经见过多次了。
普通用户使用vi编辑/etc/shadow文件会提示“Permission Denied”,这是合理的设置,但是如果赋予vi以SetUID权限:
    chmod u+s /bin/vi
ls -l /bin/vi
-rwsr-xr-x 1 root root 594740 Jun 12  2009 /bin/vi
此时,普通用户使用vi即可以编辑/etc/shadow文件,因为具备root身份,可以进行任意读写操作(比如可以把任何一个用户密码位清空,则用户登录不需要输入密码)。但是使用more、cat等命令仍然无法查看文件/etc/shadow的内容,只有被授予了SetUID的vi可以查看和修改。同样,vi如果具有了SetUID权限,普通用户可以vi编辑/etc/passwd文件把自己的UID改为0 ,则他的权限就和root一样;可以vi编辑/etc/inittab文件把缺省运行级别改成6 ,则Linux会开机后不停的重启……
 
再来看一个令人不安的情况,用普通用户尝试关闭Apache服务:      ps -le | grep httpd
140 S     0  8916     1  0  76   0    -  3697 -      ?        00:00:00 httpd
kill 8916
-bash: kill: (8916) - Operation not permitted
可以看到,普通用户不可以关闭root启动的进程,但是如果做下面一个动作:
chmod 6555 /bin/kill
现在当普通用户执行kill时,因为kill被授予了SetUID权限,在执行的一瞬间具有了root权限,只要用户不爽想关闭任何服务都可以!
 
所以,SetUID权限不能随便设置,同时要防止黑客的恶意修改,怎样避免SetUID的不安全影响,有几点建议:     1. 关键目录应严格控制写权限。比如“/”、“/usr”等;     2. 用户的密码设置要足够强壮,8位以上,大小写字母、数字、符号的组合,如:Am@ri31n,且定期更换;     3. 对系统中应该具有SetUID权限的文件作一列表,定时检查有没有这之外的文件被设置了SetUID权限。
 
可以对系统中应该具有SetUID权限的文件作一列表,定时检查有没有非列表中的命令被设置了SetUID权限。     在Linux安装部署完成后,执行下面命令生成SetUID列表文件:
mkdir /script   # 创建目录/script
find / -perm -4000 -o -perm -2000 > /script/setuid.list   
命令find选项“-perm”为指定文件权限,SetUID权限位对应数字标识为4 ,SetGID权限位对应数字标识为2 ,后面写为“000”标识对所有者所属组其他人三类用户的权限不限制;“-o”表示or,就是文件具有SetUID或者具有SetGID都在搜索之列,生成的搜索结果存放在文件/script/setuid.list中。
 
在需要对系统做检查时,执行以下shell程序。也可以放在计划任务中定时检查。
/usr/bin/find / -perm -4000 -o -perm -2000 > /tmp/setuid.check
for file in `/bin/cat /tmp/setuid.check`
do
        /bin/grep $file /script/setuid.list > /dev/null
               if [ "$?" != "0" ]
               then
                      echo "$file isn't in list! it's danger!!"
               fi
done
/bin/rm /tmp/setuid.check 假设命令kill被设置了SetUID ,则会检测提示:
/bin/kill isn't in list! it's danger!!
 
另外,如果在一些数据存放的分区想禁用SetUID功能,还可以做如下设置,编辑配置文件/etc/fstab ,找到要设置的分区(如/home)所对应的设置行:
vi /etc/fstab
LABEL=/home       /home     ext3        defaults          1     2
在设置“defaults”后,添加“nosuid”选项,并重新挂载/home分区:
vi /etc/fstab
LABEL=/home       /home     ext3        defaults,nosuid              1     2
mount -o remount /home
设置后,分区/home上任何可执行文件即使被设置了SetUID权限也无法执行(读者可自行拷贝一个SetUID命令至/home目录下执行试验),在一些存放数据、用来备份等功能的分区上做此设置,可以保护系统安全。
 
友情提示:请您作完本文中的实验后,别忘把文件的权限恢复原状,以免带来不必要的麻烦。 至此相信读者已经对SetUID的作用有所了解,最后,还有一个大家要注意的问题,SetUID只针对具有可执行权限的文件有效,不具有x权限的文件被授予了SetUID会显示标记为S ,仔细想一下,如果没有可执行权限的话设置SetUID无任何意义。

 

转自:http://apps.hi.baidu.com/share/detail/34252349

posted @ 2011-12-03 09:53  落崖惊风  阅读(497)  评论(0编辑  收藏  举报