setuid setgid

http://blog.csdn.net/oo__yan/article/details/7076889

在Linux系统中每个普通用户都可以更改自己的密码，这是合理的设置。

问题是：用户的信息保存在文件/etc/passwd中，用户的密码保存在文件/etc/shadow中，也就是说用户更改自己密码时是修改了/etc/shadow文件中的加密密码，但是，

-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文件中原来打x的地方变成了真正的加密密码。

其实，用户能更改密码真正的秘密不在于文件的权限，而在于更改密码的命令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文件会提示“PermissionDenied”，这是合理的设置，但是如果赋予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 | grephttpd

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!!

http://blog.csdn.net/oo__yan/article/details/7076889

另外，如果在一些数据存放的分区想禁用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无任何意义。