Chinaunix首页 | 论坛 | 博客
  • 博客访问: 316602
  • 博文数量: 42
  • 博客积分: 451
  • 博客等级: 下士
  • 技术积分: 890
  • 用 户 组: 普通用户
  • 注册时间: 2011-03-03 18:24
文章分类

全部博文(42)

文章存档

2015年(1)

2013年(9)

2012年(19)

2011年(13)

分类:

2011-06-28 14:39:09

Linux权限360度赤裸裸华丽丽大曝光连载之二:深入理解SetUID
                                               
                                                           LAMP兄弟连 李明(ID:肥同小可)
                                                           Email/QQ:
 
                                          [原创文章,转载请注明作者及出处,谢谢]
 
    本文为Linux权限系列文章的第二篇,计划总计三篇终结。
 

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有读写权限,也就是说普通用户对这两个文件都没有写权限无法写入新密码,为什么普通用户可以更改密码呢?

PSLinux中设置或更改用户密码,是先写入到/etc/passwd文件然后通过pwconv命令转换到/etc/shadow文件,执行pwunconv命令可观察到转换前效果,会观察到/etc/shadow文件神奇的消失掉了,而/etc/passwd文件中原来打x的地方变成了真正的加密密码。

 

其实,用户能更改密码真正的秘密不在于文件的权限,而在于更改密码的命令passwd

-rwsr-xr-x 1 root root 22960 Jul 17  2006 /usr/bin/passwd

passwd命令有一个特殊的权限标记s ,存在于文件所有者的权限位上。这是一类特殊的权限SetUID ,可以这样来理解它:当一个具有执行权限的文件设置SetUID权限后,用户执行这个文件时将以文件所有者的身份执行passwd命令具有SetUID权限,所有者为rootLinux中的命令默认所有者都是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命令为例做一演示。

普通用户samleetouch创建文件newfile01

touch newfile01

ls -l newfile01

-rw-rw-r-- 1 samlee samlee 0 05-21 01:20 newfile01

文件的创建者默认就是所有者,所以文件newfile01的所有者为samlee

管理员roottouch命令添加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,这是合理的设置,但是如果赋予viSetUID权限:

    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身份,可以进行任意读写操作(比如可以把任何一个用户密码位清空,则用户登录不需要输入密码)。但是使用morecat等命令仍然无法查看文件/etc/shadow的内容,只有被授予了SetUIDvi可以查看和修改。同样,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(一下子由小s变成姐姐了)仔细想一下,如果没有可执行权限的话设置SetUID无任何意义。

 

——

http://blog.chinaunix.net/space.php?uid=20168535&do=blog&id=330500

 

 

阅读(1202) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~