深入理解SetUID ************************888

而内核检查一个进程是否具有访问某权限时,是使用进程的有效用户 ID 来进行检查的。

 

 

用 setuid() 设置实际用户 UID 和有效用户 UID。
用 setgid() 设置实际组 ID 和有效组 ID。

两个函数声明如下
setuid()与setgid() <wbr>-- <wbr>设置 <wbr>UID <wbr>和 <wbr>GID
在使用该函数时会遇到以下情况:
1. 若进程有 root 权限,则函数将实际用户 ID、有效用户 ID 设置为参数 uid 。使用 root 运行下面代码:
setuid()与setgid() <wbr>-- <wbr>设置 <wbr>UID <wbr>和 <wbr>GID
运行输出:
引用
# ./setuid.exe 1001
real uid: 0
effective uid: 0
real uid: 1001
effective uid: 1001

由此可见,在 root 下,实际用户 ID 和有效用户 ID 均被设为 setuid() 的参数 uid 的值。

2. 若进程不具有 root 权限,那么普通用户使用 setuid() 时参数 uid 只能是自己的,没有权限设置别的数值,否则返回失败:
引用
$ ./setuid.exe 1001
real uid: 1000
effective uid: 1000
setuid error: Operation not permitted
real uid: 1000
effective uid: 1000


由以上可以看出,只有超级用户进程才能更改实际用户 ID 。所以一个非特权用户进程不能通过 setuid 或 seteuid 得到特权用户权限。但是 su 命令却能使一个普通用户变成特权用户。这并不矛盾,因为 su 是一个 "set_uid" 程序。执行一个设置了 "set_uid" 位的程序时,内核将进程的有效用户 ID 设置为文件属主的 ID(root 的 ID)。而内核检查一个进程是否具有访问某权限时,是使用进程的有效用户 ID 来进行检查的。su 程序的文件属主是 root,普通用户运行 su 命令时,su 进程的权限是 root 权限。 

Warning:对于调用了 setuid() 函数的程序要格外小心,当进程的有效用户 ID 即 euid 是 root 用户时,如果调用 setuid() 使 euid 为其他非 root 用户,则该进程从此就不具有超级用户权限了。看下面代码:
setuid()与setgid() <wbr>-- <wbr>设置 <wbr>UID <wbr>和 <wbr>GID
我们使用 root 编译上面的程序,并运行 chmod u+s 给程序添加 suid 位,然后以普通用户来运行它。
在上面程序中,在运行 setuid (1000) 函数时,我们还是具有 root 权限的,所以该函数会设置成功。正是因为有了 root 权限,所以 3 个 ID (真实用户ID,已保存用户ID,有效用户ID)都会被设置为 1000。所以此后程序已经被降权为普通用户,想再  seteuid (0) 已经不可能。

可以这样使用 stuid() 函数
开始时,某个程序需要 root 权限玩成一些工作,但后续的工作不需要 root 权限。可以将该可执行程序文件设置 set_uid 位,并使得该文件的属主为 root。这样,普通用户执行这个程序时,进程就具有了 root 权限,当不再需要 root 权限时,调用 setuid( getuid() ) 恢复进程的实际用户 ID 和有效用户 ID 为执行该程序的普通用户的 ID 。对于一些提供网络服务的程序,这样做是非常有必要的,否则就可能被攻击者利用,使攻击者控制整个系统。

对于设置了 set_uid 位的可执行程序也要注意,尤其是对那些属主是 root 的更要注意。因为 Linux 系统中 root 用户拥有最高权力。黑客们往往喜欢寻找设置了 set_uid 位的可执行程序的漏洞。这样的程序如果存在缓冲区溢出漏洞,并且该程序是一个网络程序,那么黑客就可以从远程的地方轻松地利用该漏洞获得运行该漏洞程序的主机的 root 权限。即使这样的成不是网络程序,那么也可以使本机上的恶意普通用户提升为 root 权限。

 

 

 

在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的作用。
 
 -rw--w--w- 1 yangzongde root 0 Jun 7 19:35 testfile //查看文件拥有者为 yangzongde,但组仍为 root 
 
再看一下与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无任何意义。
 
 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值