setUID命令只能对文件生效,对目录不生效
在使用umask命令查看系统默认权限时,会出现4位数字的权限代号,如下:
其中第一个0表示的其实就是文件的特殊权限,包括setUID,setGID,sticky BIT权限,其于文件的用户对应的关系为:
特殊权限名 | 对应用户 | 对应权限代号 |
setUID | u(所有者) | 4 |
setGID | g(所属组) | 2 |
sticky BIT | o(其他用户) | 1 |
当没设置文件的特殊权限(包括setUID,setGID,sticky BIT权限)时,对应的四位数字的第一位则为0。
1、setUID权限的功能
- 只有可执行(x)的二进制程序才能设定setUID权限
- 命令执行者要对该程序拥有执行权限(x)
- 命令的执行者在执行该程序时会获得该程序文件的属主身份(在执行程序的过程中灵魂附体为文件的属主)
- setUID权限只在该程序的执行过程中有效,也就是说身份改变只在程序执行过程中有效
2、给文件设定setUID权限
chmod 4755 文件名
#下面的这个是个例子
chmod 4755 abc
#或者
chmod u+s abc
结果如下:
可以看出赋予了setUID权限后对应原来所有者身份的rwx变成了rws,也就是s取代了x,同时系统把文件名abc以红底白字显示(提示这个文件是不安全的,有可能有安全隐患,也就是setUID权限不安全)
如果给一个没有可执行权限的文件赋予setUID权限,那么结果为:
即对应的rw-会变成rwS,这种大S权限的(setUID权限)文件是不可执行的,没什么意义,因此需给文件的属主可执行权限再赋予setUID权限才有意义。
3、获得该程序文件的属主身份的特性(危险)
在linux中用户的密码都放在/etc/shadow文件下,而且该文件的权限都是0,即只有root用户才能打开该文件,普通用户打开该文件会提示权限不足。(当然赋予了sudo权限的用户也能打开)
那既然普通用户不能访问/etc/shadow文件,那么linux中的普通用户自己怎么修改自己的密码呢?这里就涉及到系统设计好的setUID权限。如下:
对于/usr/bin/passwd命令,系统已经预先设置为了rwsr-xr-x权限
所以普通用户执行passwd命令期间,普通用户将会得到passwd命令的属主(root)的身份,因此就可以访问/etc/shadow文件,实现自身密码的修改。
4、危险的setUID
如果系统中存在默认setUID权限之外的带有setUID权限的文件,则有可能被别人植入了木马或者其他危险文件,因此在一般的日常工作中,能够不用setUID权限就能完成的工作,就尽量不要使用setUID权限。并且做好如下几个方面的工作:
- 关键目录应该严格控制写权限。比如:“/”、“/usr”等
- 用户的密码设置要严格遵守密码三原则
- 对系统中默认具有setUID权限的文件作一列表,定时检查有没有这之外的文件被设置了setUID权限
5、定时检查系统中有无系统默认之外的具有setUID权限的文件脚本
#!/bin/bash
find / -perm -4000 -o -perm -2000 > /tmp/setuid.check
#搜索系统中所有拥有setUID和setGID的文件,并保存到临时目录setuid.check中
for i in $(cat /tmp/setuid.check)
#做循环,每次循环取出临时文件中的文件名
do
grep $i /home/fz/suid.log > /dev/null
#比对这个文件名是否在模板文件中
if [ "$?" != "0" ]
#检查上一个命令的返回值,如果不为0,证明上一个命令报错
then
echo "$i isn't in listfile!" > /home/fz/suid_log_$(date +%F)
#如果文件名不在模板文件中,则输出错误信息,并把错误信息报错到日志中
fi
done
rm -rf /tmp/setuid.check
#删除临时文件
首先在检查前,先把系统中自带的setUID权限的文件找出来,并将其写入/home/fz/suid.log文件中,然后再执行此脚本。