关于linux/unix中SUID/SGID说明

来源:互联网 发布:php高并发面试题 编辑:程序博客网 时间:2024/06/05 21:02
关于linux/unix中SUID/SGID说明

由于用户在UNIX下经常会遇到SUID、SGID的概念,而且SUID和SGID涉及到系统安全,所以用户也比较关心这个问题。

一、UNIX下关于文件权限的表示方法和解析

SUID 是 Set User ID, SGID 是 Set Group ID的意思。

UNIX下可以用ls -l 命令来看到文件的权限。用ls命令所得到的表示法的格式是类似这样的:-rwxr-xr-x 。下面解析一下格式所表示的意思。这种表示方法一共有十位:

9 8 7 6 5 4 3 2 1 0

- r w x r - x r - x

第9位表示文件类型,可以为p、d、l、s、c、b和-:

p表示命名管道文件

d表示目录文件

l表示符号连接文件

-表示普通文件

s表示socket文件

c表示字符设备文件

b表示块设备文件

第8-6位、5-3位、2-0位分别表示文件所有者的权限,同组用户的权限,其他用户的权限,其形式为rwx:

r表示可读,可以读出文件的内容

w表示可写,可以修改文件的内容

x表示可执行,可运行这个程序

没有权限的位置用-表示

例子:

ls -l myfile显示为:

-rwxr-x--- 1 foo staff 7734 Apr 05 17:07 myfile

表示文件myfile是普通文件,文件的所有者是foo用户,而foo用户属于staff组,文件只有1个硬连接,长度是7734个字节,最后修改时间4月5日17:07。

所有者foo对文件有读写执行权限,staff组的成员对文件有读和执行权限,其他的用户对这个文件没有权限。

如果一个文件被设置了SUID或SGID位,会分别表现在所有者或同组用户的权限的可执行位上。例如:

1、-rwsr-xr-x 表示SUID和所有者权限中可执行位被设置

2、-rwSr--r-- 表示SUID被设置,但所有者权限中可执行位没有被设置

3、-rwxr-sr-x 表示SGID和同组用户权限中可执行位被设置

4、-rw-r-Sr-- 表示SGID被设置,但同组用户权限中可执行位没有被社

其实在UNIX的实现中,文件权限用12个二进制位表示,如果该位置上的值是

1,表示有相应的权限:

11 10 9 8 7 6 5 4 3 2 1 0

S G T r w x r w x r w x

第11位为SUID位,第10位为SGID位,第9位为sticky位,第8-0位对应于上面的三组rwx位。

11 10 9 8 7 6 5 4 3 2 1 0

上面的-rwsr-xr-x的值为: 1 0 0 1 1 1 1 0 1 1 0 1

-rw-r-Sr--的值为: 0 1 0 1 1 0 1 0 0 1 0 0

给文件加SUID和SUID的命令如下

chmod u+s filename 设置SUID位

chmod u-s filename 去掉SUID设置

chmod g+s filename 设置SGID位

chmod g-s filename 去掉SGID设置

另外一种方法是chmod命令用八进制表示方法的设置。如果明白了前面的12位权限表示法也很简单。

二、SUID和SGID的详细解析

由于SUID和SGID是在执行程序(程序的可执行位被设置)时起作用,而可执行位只对普通文件和目录文件有意义,所以设置其他种类文件的SUID和SGID位是没有多大意义的。

首先讲普通文件的SUID和SGID的作用。例子:

如果普通文件myfile是属于foo用户的,是可执行的,现在没设SUID位,ls命令显示如下:

-rwxr-xr-x 1 foo staff 7734 Apr 05 17:07 myfile任何用户都可以执行这个程序。UNIX的内核是根据什么来确定一个进程对资源的访问权限的呢?是这个进程的运行用户的(有效)ID,包括user id和group id。用户可以用id命令来查到自己的或其他用户的user id和group id。

除了一般的user id 和group id外,还有两个称之为effective 的id,就是有效id,上面的四个id表示为:uid,gid,euid,egid。内核主要是根据euid和egid来确定进程对资源的访问权限。

一个进程如果没有SUID或SGID位,则euid=uid egid=gid,分别是运行这个程序的用户的uid和gid。例如kevin用户的uid和gid分别为204和202,foo用户的uid和gid为200,201,kevin运行myfile程序形成的进程的euid=uid=204,egid=gid=202,内核根据这些值来判断进程对资源访问的限制,其实就是kevin用户对资源访问的权限,和foo没关系。

如果一个程序设置了SUID,则euid和egid变成被运行的程序的所有者的uid和gid,例如kevin用户运行myfile,euid=200,egid=201,uid=204,gid=202,则这个进程具有它的属主foo的资源访问权限。

SUID的作用就是这样:让本来没有相应权限的用户运行这个程序时,可以访问他没有权限访问的资源。passwd就是一个很鲜明的例子。

SUID的优先级比SGID高,当一个可执行程序设置了SUID,则SGID会自动变成相应的egid。

下面讨论一个例子:

UNIX系统有一个/dev/kmem的设备文件,是一个字符设备文件,里面存储了核心程序要访问的数据,包括用户的口令。所以这个文件不能给一般的用户读写,权限设为:cr--r----- 1 root system 2, 1 May 25 1998 kmem

但ps等程序要读这个文件,而ps的权限设置如下:

-r-xr-sr-x 1 bin system 59346 Apr 05 1998 ps

这是一个设置了SGID的程序,而ps的用户是bin,不是root,所以不能设置SUID来访问kmem,但大家注意了,bin和root都属于system组,而且ps设置了SGID,一般用户执行ps,就会获得system组用户的权限,而文件kmem的同组用户的权限是可读,所以一般用户执行ps就没问题了。但有些人说,为什么不把ps程序设置为root用户的程序,然后设置SUID位,不也行吗?这的确可以解决问题,但实际中为什么不这样做呢?因为SGID的风险比SUID小得多,所以出于系统安全的考虑,应该尽量用SGID代替SUID的程序,如果可能的话。下面来说明一下SGID对目录的影响。SUID对目录没有影响。如果一个目录设置了SGID位,那么如果任何一个用户对这个目录有写权限的话,他在这个目录所建立的文件的组都会自动转为这个目录的属主所在的组,而文件所有者不变,还是属于建立这个文件的用户。

三、关于SUID和SGID的编程

和SUID和SGID编程比较密切相关的有以下的头文件和函数:

#include

#include

uid_t getuid(void);

uid_t geteuid(void);

gid_t getgid (void);

gid_t getegid (void);

int setuid (uid_t UID);

int setruid (uid_t RUID);

int seteuid (uid_t EUID);

int setreuid (uid_t RUID,uid_t EUID);

int setgid (gid_t GID);

int setrgid (gid_t RGID);

int setegid (git_t EGID);

int setregid (gid_t RGID, gid_t EGID);

具体这些函数的说明在这里就不详细列出来了,要用到的可以用man查。

SUID/SGID :

假如你有文件a.txt

#ls -l a.txt

-rwxrwxrwx

#chmod 4777 a.txt

-rwsrwxrwx ======>注意s位置

#chmod 2777 a.txt

-rwxrwsrwx ======>注意s位置

#chmod 7777 a.txt

-rwsrwxswt ======>出现了t,t的作用在内存中尽量保存a.txt,节省系统再加载的时间.

现在再看前面设置 SUID/SGID作用:

#cd /sbin

#./lsusb

...

#su aaa(普通用户)

$./lsusb

...

是不是现在显示出错?

$su

#chmod 4755 lsusb

#su aaa

$./lsusb

... 现在明白了吗?本来是只有root用户才能执行的命令,加了SUID后,普通用户就可以像root一样的用,权限提升了。上面是对于文件来说的,对于目录也差不多!

目录的S属性使得在该目录下创建的任何文件及子目录属于该目录所拥有的组,目录的T属性使得该目录的所有者及root才能删除该目录。还有对于s与S,设置SUID/SGID需要有运行权限,否则用ls -l后就会看到S,证明你所设置的SUID/SGID没有起作用。

Why we need suid,how do we use suid?

r -- 读访问

w -- 写访问

x -- 执行许可

s -- SUID/SGID

t -- sticky位

那么 suid/sgid是做什么的? 为什么会有suid位呢?

要想明白这个,先让我们看个问题:如何让每个用户更改自己的密码?

用户修改密码,是通过运行命令passwd来实现的。最终必须要修改/etc/passwd文件,而passwd的文件的属性是:

#ls -l /etc/passwd

-rw-r--r-- 1 root root 2520 Jul 12 18:25 passwd

我们可以看到passwd文件只有对于root用户是可写的,而对于所有的他用户来说都是没有写权限的。 那么一个普通的用户如何能够通过运行passwd命令修改这个passwd文件呢?

为了解决这个问题,SUID/SGID便应运而生。而且AT&T对它申请了专利。 呵呵。

SUID和SGID是如何解决这个问题呢?

首先,我们要知道一点:进程在运行的时候,有一些属性,其中包括 实际用户ID,实际组ID,有效用户ID,有效组ID等。 实际用户ID和实际组ID标识我们是谁,谁在运行这个程序,一般这2个字段在登陆时决定,在一个登陆会话期间, 这些值基本上不改变。

有效用户ID和有效组ID则决定了进程在运行时的权限。内核在决定进程是否有文件存取权限时,是采用了进程的有效用户ID来进行判断的

知道了这点,我们来看看SUID的解决途径:

当一个程序设置了为SUID位时,内核就知道了运行这个程序的时候,应该认为是文件的所有者在运行这个程序。即该程序运行的时候,有效用户ID是该程序的所有者。举个例子:

[root@sgrid5 bin]# ls -l passwd

-r-s--s--x 1 root root 16336 Feb 14 2003 passwd

虽然你以test登陆系统,但是当你输入passwd命令来更改密码的时候,由于passwd设置了SUID位,因此虽然进程的实际用户ID是test对应的ID,但是进程的有效用户ID则是passwd文件的所有者root的ID,因此可以修改/etc/passwd文件。

让我们看另外一个例子。

ping命令应用广泛,可以测试网络是否连接正常。ping在运行中是采用了ICMP协议,需要发送ICMP报文。但是只有root用户才能建立ICMP报文,如何解决这个问题呢?同样,也是通过SUID位来解决。

[root@sgrid5 bin]# ls -l /bin/ping

-rwsr-sr-x 1 root root 28628 Jan 25 2003 /bin/ping

我们可以测试一下,如果去掉ping的SUID位,再用普通用户去运行命令,看会怎么样。

[root@sgrid5 bin]#chmod u-s /bin/ping

[root@sgrid5 bin]# ls -l ping

-rwxr-xr-x 1 root root 28628 Jan 25 2003 ping

[root@sgrid5 bin]#su test

[test@sgrid5 bin]$ ping byhh.net

ping: icmp open socket: Operation not permitted

SUID虽然很好了解决了一些问题,但是同时也会带来一些安全隐患。

因为设置了 SUID 位的程序如果被攻击(通过缓冲区溢出等方面),那么hacker就可以拿到root权限。

因此在安全方面特别要注意那些设置了SUID的程序。

通过以下的命令可以找到系统上所有的设置了suid的文件:

[root@sgrid5 /]# find / -perm -04000 -type f -ls

对于这里为什么是4000,大家可以看一下前面的st_mode的各bit的意义就明白了。

在这些设置了suid的程序里,如果用不上的,就最好取消该程序的suid位。

[root@rhe5 /]# find / -perm -04000 -type f -ls 
find: /proc/12922/task/12922/fd/4: No such file or directory 
find: /proc/12922/fd/4: No such file or directory 
75023   64 -rwsr-xr-x   1 root     root        55016 Dec 19  2006 /sbin/mount.nfs4 
71001   16 -rwsr-xr-x   1 root     root        12280 Jan 16  2007 /sbin/pam_timestamp_check 
75022   64 -rwsr-xr-x   1 root     root        55012 Dec 19  2006 /sbin/mount.nfs 
75026   64 -rwsr-xr-x   1 root     root        55016 Dec 19  2006 /sbin/umount.nfs 
75027   64 -rwsr-xr-x   1 root     root        55016 Dec 19  2006 /sbin/umount.nfs4 
71002   28 -rwsr-xr-x   1 root     root        20796 Jan 16  2007 /sbin/unix_chkpwd 
639362    4 -r-s---r-T   1 root     root            0 Jan 16 23:01 /media/.hal-mtab-lock 
447629   68 -rwsr-xr-x   1 root     root        57588 Jan 12  2007 /bin/mount 
447571   40 -rwsr-xr-x   1 root     root        35864 Dec 21  2006 /bin/ping 
447572   36 -rwsr-xr-x   1 root     root        31244 Dec 21  2006 /bin/ping6 
447554   44 -rwsr-xr-x   1 root     root        38552 Jan 12  2007 /bin/umount 
447606   28 -rwsr-xr-x   1 root     root        24060 Nov 28  2006 /bin/su 
939398   12 -rwsr-xr-x   1 root     root         6808 Jan 16  2007 /usr/sbin/usernetctl 
    55   40 -rws--x--x   1 root     root        34824 Dec 11  2006 /usr/sbin/userhelper 
942148   12 -rwsr-xr-x   1 root     root         6416 Aug 23  2006 /usr/sbin/ccreds_validate 
947009  164 ---s--x--x   2 root     root       159096 Oct  2  2006 /usr/bin/sudo 
935137   24 -rwsr-xr-x   1 root     root        18544 Nov 28  2006 /usr/bin/rcp 
947009  164 ---s--x--x   2 root     root       159096 Oct  2  2006 /usr/bin/sudoedit 
939580  312 -rwsr-sr-x   1 root     root       311288 Dec 30  2006 /usr/bin/crontab 
935140   16 -rwsr-xr-x   1 root     root         8876 Nov 28  2006 /usr/bin/rsh 
255789 1788 -rws--x--x   1 root     root      1820868 Jan 10  2007 /usr/bin/Xorg 
937989   52 -rwsr-xr-x   1 root     root        46748 Jan 17  2007 /usr/bin/chage 
255770   24 -rws--x--x   1 root     root        19064 Jan 12  2007 /usr/bin/chsh 
933929   52 -rwsr-xr-x   1 root     root        47352 Jan 17  2007 /usr/bin/gpasswd 
934168   28 -rwsr-xr-x   1 root     root        24556 Jan 17  2007 /usr/bin/newgrp 
941107   24 -rws--x--x   1 root     root        17900 Jan 12  2007 /usr/bin/chfn 
935139   20 -rwsr-xr-x   1 root     root        13108 Nov 28  2006 /usr/bin/rlogin 
940114   48 -rwsr-xr-x   1 root     root        44040 Aug 23  2006 /usr/bin/at 
319945   28 -rwsr-xr-x   1 root     root        22960 Jul 17  2006 /usr/bin/passwd 
192161  180 -rwsr-xr-x   1 root     root       172200 Jan 12  2007 /usr/libexec/openssh/ssh-keysign 
227583  152 -rwsr-xr-x   1 root     root       144537 Jan 17  2007 /usr/kerberos/bin/ksu 
416510   60 -r-sr-xr-x   1 root     root        51424 Jan 16 23:02 /usr/lib/vmware-tools/sbin64/vmware-hgfsmounter 
415586   52 -r-sr-xr-x   1 root     root        47448 Jan 16 23:02 /usr/lib/vmware-tools/sbin32/vmware-hgfsmounter 
234428   16 -r-sr-xr-x   1 root     root         8456 Jan 16 23:03 /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper 
228649   16 -r-sr-xr-x   1 root     root         8516 Jan 16 23:03 /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper 
[root@rhe5 /]#

 

==================================================================================

一、 SUID/SGID概述

有时,没有被授权的用户需要完成某项任务。一个例子是passwd程序,它允许用户改变口令,这就要求改变/etc/passwd文件的口令域。然而系统管理员决不允许普通用户拥有直接改变这个文件的权利,因为这绝对不是一个好主意。 
为了解决这个问题,SUID/SGID便应运而生。UNIX允许程序被授权,当程序被执行的时候,拥有超级用户的权限,完成时又回到普通用户的权限。这个主意很好,所以AT&T对它申请了专利。

二、 UNIX下的一些名词简介

1.文件权限。确定用户读取、修改或执行文件的权力。 
r -- 读访问 
w -- 写访问 
x -- 执行许可 
s -- SUID/SGID 
t -- sticky位 
2.进程。进程是程序运行一次的过程,以完成预定的任务,它不同于程序。每个进程都有一个唯一的进程ID。此外,每个进程还有一些其他标识符:实际用户ID、实际组ID、有效用户ID、有效组ID。超级用户进程的实际用户ID和有效用户ID为0。 
3.超级用户root。超级用户拥有系统的完全控制权。

三、 SUID/SGID的思路

SUID的程序在运行时,将有效用户ID改变为该程序的所有者ID,使得进程在很大程度上拥有了该程序的所有者的特权。如果被设置为SUID root,那么这个进程将拥有超级用户的特权(当然,一些较新版本的UNIX系统加强了这一方面的安全检测,一定程度上降低了安全隐患)。当进程结束时,又恢复为原来的状态。

  注:SUID/SGID程序在执行时的Real Uid可以通过函数setuid()改变

四、一个SUID程序

下面的程序是用来演示UNIX文件的SUID,取名为parent.c

#include 〈stdio.h〉 
#include 〈stdlib.h〉 
#include 〈unistd.h〉 
#include 〈sys/types.h〉 
int 
main(int argc,char **argv) 

int i; 
char **argu; 
uid_t uid; 
uid=geteuid(); //获取调用进程的有效用户ID 
if(argc<2){ 
fprintf(stderr,"usage: %s \n",argv[0]); 
exit(0); 

if(setuid(uid)<0){ 
fputs("setuid error.\n",stderr); 
exit(1); 
} //将调用进程的实际用户ID设置为有效用户ID 
if((argu=(char**)malloc(argc*sizeof(char*)))==NULL){ 
fputs("malloc error.\n",stderr); 
exit(1); 
} //为execvp的参数指针数组分配内存空间 
for(i=0;i 
argu[argc-1]=(char *)0; //参数指针数组以空指针结尾 
if(execvp(argv[1],argu)<0){ 
fputs("exec error.\n",stderr); 
exit(1); 
} //用execvp调用命令行参数指定的程序 
exit(0); 
}

该程序将一个SUID的进程转变为一个超级用户进程。将此程序编译成可执行目标文件parent ,用另一个简单的程序进行检验

int main(void){ 
printf("real uid=%d, effective uid=%d\n",getuid(),geteuid()); 
exit(0); 
}

编译为printuids。运行程序得到下列结果:

$ ./parent printuids //正常执行,无特权 
real uid=506, effective uid=506 
$ su root 
Password: 
# chown root parent //更改所有者 
# chmod u+s parent //添加SUID 
# exit 
$ ./parent printuidsv real uid=0, effective uid=0 //该进程转变为超级用户进程

某一进程一旦转变为超级用户进程,将拥有系统的完全控制权。比如,我们可以这样执行演示程序: $ ./parent useradd hacker 
$ ./parent passwd hacker 
故而,SUID的程序往往伴随着一定的安全问题。在早期的UNIX环境中,SUID/SGID的程序调用system()函数就存在着安全性漏洞。

五、 再谈SUID/SGID程序的安全问题

有时,一个SUID程序与一个系统程序(或库函数)之间的交互作用会产生连程序的编制者也不知道的安全漏洞。一个典型的例子是/usr/lib/preserve程序。它被vi和ex编辑器使用,当用户在写出对文件的改变前被意外与系统中断时,它可以自动制作一个正被编辑的文件的拷贝。这个保存的(preserve)程序将改变写到在一个专门的目录内的一个临时文件上,然后利用/bin/mail程序发送给用户一个"文件已经被存"的通知。 
由于人们可能正在编辑一个私人的或一个机密的文件,被preserve程序(旧版)使用的那个目录不能被一般用户访问。为了使preserve程序可以写入那个目录,以及使recover程序可以从那里读,这些程序被设置为SUID root。 这个preserve程序有三个特点值得注意: 
1. 这个程序被设置为SUID root。 
2. 该程序以root用户的身份运行/bin/mail程序。 
3. 该程序调用system()函数调用mail程序。 
由于system()函数调用shell对命令字符串进行语法分析,而shell则使用IFS变量作为其输入字段的分割符。早期的shell版本在被调用是时不将此变量恢复为普通字符集。如果先将IFS设置为"/",然后调用vi程序,继而调用preserve程序,就有可能使usr/lib/preserve程序执行一个在当前目录下的bin程序(/bin/mail被解析为带有参数mail的bin程序)。
如果我们利用前面的演示程序编写一个简单的shell script文件命名为bin,它就有可能通过上面的安全漏洞被执行:

# shell script to make an SUID-root 
shell 

chown root parent 
chmod 4755 parent