Linux文件权限与属性详解 之 SUID、SGID & SBIT

前言

我们有时候在操作Linux系统的时候,往往会遇到一些奇怪的字符,例如对某一个文件/目录执行ll时,可能会出现以下情况:

[niesh@niesh~]$ ll /usr/bin/passwd

-rwsr-xr-x.1 root root 278326月102014 /usr/bin/passwd

[niesh@niesh~]$ ll -d /tmp

/drwxrwxrwt.15 root root 4096 7月3016:20 /tmp/

懵逼了,以前见到的都是 r w x,什么时候出来了s t了?这俩是啥东东?

其实,上面就是Linux文件/目录的特殊权限了 - SetUIDSetGID 和 SBIT

呃,这仨优势啥鸟货?下面我给你慢慢解释,你们先打个照面!



SetUID

试想一个场景:

Linux普通用户可以修改自己的密码,这个是一个合情合理的设置;修改密码其实修改的是 /etc/shadow 这个文件;然而不知道你有没看过这个文件的属性:

[niesh@niesh~]$ ll /etc/shadow

----------.1 root root 1476 7月3016:15 /etc/shadow

我去,bug啊?很明显普通用户对 /etc/shadow 文件没有任何权限啊,那怎么可能修改该文件呢?

一方面我们需要修改自己的密码(就是修改/etc/shadow),另一方面这个文件对普通用户没任何权限,自相矛盾啊?这么办呢?

其实,这里就牵扯到了 SetUID 权限:修改密码的流程其实就是通过 /usr/bin/passwd 命令对 /etc/passwd进行修改,那么先让我们看一下这个可执行文件的属性:

[niesh@niesh~]$ ll /usr/bin/passwd

-rwsr-xr-x.1 root root 278326月 102014 /usr/bin/passwd

发现/usr/bin/passwd的权限为:-rwsr-xr-x. 在此“文件所有者”的第三位是s权限,也就是咱们即将要详细讲解的的setUID权限,也就是它在作怪了!

不相信,那行,我现在验证一下(和cat命令对比):

[niesh@niesh~]$ passwd   #更改用户 niesh 的密码 。

为 niesh 更改 STRESS 密码。

(当前)UNIX 密码:新的 密码:

[niesh@niesh~]$ ll /usr/bin/cat

-rwxr-xr-x.1 root root 54048 11月202015 /usr/bin/cat

[niesh@niesh~]$ cat /etc/shadow

cat:/etc/shadow:权限不够

SetUID(或者 s 权限):当一个具有执行权限的文件设置SetUID权限后,用户执行这个文件时将以文件所有者的身份执行。passwd命令具有SetUID权限,所有者为root(Linux中的命令默认所有者都是root),也就是说当普通用户使用passwd更改自己密码的时候,那一瞬间突然 “灵魂附体” 了,实际在以passwd命令所有者root的身份在执行,root当然可以将密码写入/etc/shadow文件(root是一个bug的存在,在Linux中就没有它不能干的事),命令执行完成后该身份也随之消失。

0. SetUID条件:

必须具备以下几个条件(前提):

只有可执行的二进制程序才可以设置SetUID

所有者必须对欲设置SetUID的文件具备 可执行(x) 权限

命令执行过程中,其它用户获取所有者的身份(灵魂附体)

SetUID具有时间限制,即完成该程序执行后就消失(不能霸占住不放吧?)

1. 设置和取消SetUID

设置SetUID

chmod 4xxx < file-name >

chmod u+s < file-name >

取消SetUID

chmod xxx < file-name >

chmod u-s < file-name >

2. 例程

首先,查看一下touch命令的属性:

[niesh@nieshtmp]$ ll /usr/bin/touch

-rwxr-xr-x.1 root root 62432 11月202015 /usr/bin/touch

然后,用普通用户创建一个文件:

[niesh@niesh tmp]$ touch test1

[niesh@niesh tmp]$ ll test1

-rw-rw-r--.1 niesh niesh 07月3017:40 test1

接着,更改touch的属性,增加SetUID属性:

[niesh@nieshtmp]$ sudo chmod u+s /usr/bin/touch

[sudo] password for niesh:

[niesh@nieshtmp]$ ll /usr/bin/touch

-rwsr-xr-x.1 root root 62432 11月202015 /usr/bin/touch

而后,用普通用户再新建一个文件:

[niesh@niesh tmp]$ touch test2

最后,查看两个新建文件的属性:

[niesh@niesh tmp]$ ll test1 test2

-rw-rw-r--.1 niesh niesh 07月3017:40 test1

-rw-rw-r--.1 root  niesh 07月3017:42 test2

[niesh@niesh tmp]$

可以看到,在设置了SetUID之后,新建文件的所有者为root了,说明在执行touch的时候,用户自动升级为了所有者,灵魂附体了!

3. 危险性

设置SetUID是具备很大危险性的,例如赋予 vim 这个权限:

首先,查找vim在哪里

[root@niesh ~]# whereis vim

vim:/usr/bin/vim /usr/bin/vim.tiny /usr/local/bin/vim /usr/local/vim /usr/share/vim

然后,查看vim的属性

[root@niesh ~]# ll /usr/bin/vim

lrwxrwxrwx.1 root root 18 5月12 1:02 /usr/bin/vim ->/usr/local/bin/vim

再次,给vim增加SetUID权限

[root@niesh ~]# chmod u+s /usr/bin/vim

[root@niesh ~]# ll /usr/bin/vim

lrwxrwxrwx.1 root root 18 5月12 1:02 /usr/bin/vim ->/usr/local/bin/vim

最后,使用vim编辑/etc/shadow

[niesh@niesh ~]# vim /etc/shadow

明显,我可以打开并进行编辑了,那万一,一个不懂的人或者而已破坏的人将自己的权限提升到了root或者干脆删除这里的内容,那后果将是灾难性的!

所以,我们需要定时查看系统中有哪些设置了SetUID权限,对不明物体进行实时打击!



SetGID

其实,SetGID基本与SetUID相同,无非也就是一个设置所有者的权限,GID为设置所属组的特殊权限!

区别点在于:SetGID也可以设置目录的相关SetGID权限!

0. SetGID条件:

针对文件

可执行的二进制文件

命令执行者(即所属组)对该文件具备 x 权限

执行时,执行者被所属组灵魂附体

权限只在执行过程中有效

针对目录

普通用户对目录具备r和x权限,才可以进入到该目录

普通用户在此目录中的有效组会变成此目录的所属组

如普通用户对该目录具备w权限,新建文件的所属组为该目录的所属组

1. 设置和取消SetGID

设置SetGID

chmod 2xxx

取消SetGID

chmod xxx

2. 例程:

我们此处以locate命令进行讨论:

locate查询命令,比find要快很多,为什么?因为其实搜索的数据库而非整个硬盘:

[root@niesh ~]# ll /usr/bin/locate

-rwx--s--x.1 root slocate 40496 6月10 2014 /usr/bin/locate

[root@niesh ~]# ll /var/lib/mlocate/mlocate.db

-rw-r-----.1 root slocate 6306909 7月30 19:15 /var/lib/mlocate/mlocate.db

我用普通用户进行locate查看:

[niesh@nieshroot]$ locate mlocate.db/usr/share/man/man5/mlocate.db.5.gz

去掉locate的s权限:

[root@niesh ~]# chmod g-s /usr/bin/locate

[root@niesh ~]# ll /usr/bin/locate

-rwx--x--x. 1 root slocate 40496 6月 10 2014 /usr/bin/locate

[niesh@nieshroot]$ locate mlocate.dblocate:无法执行 stat () `/var/lib/mlocate/mlocate.db': 权限不够

也就是:当执行locate命令时,普通用户niesh自动升级为slocate的组成员。



SBIT

Stick Bit,粘滞位。

0.作用:

只对目录有效

普通用户对该目录有w和x权限

若没有粘滞位,则普通用户可以对目录下的文件/子目录进行删除操作(因为普通用户对目录具有w权限),包括其它用户建立的目录/文件;但若赋了SBIT,则普通用户只能删除自己创建的文件/目录,而不能删除不属于自己的文件/目录!

1. 设置和取消SBIT

设置SBIT

chmod 1xxx < dir-name >

chmod o+t < dir-name >

取消SBIT

chmod xxx < dir-name >

chmod o-t < dir-name >

2. 例程

以/tmp为例:

查看/tmp的权限:

[niesh@niesh tmp]$ ll -d /tmp/

drwxrwxrwt. 8 root root 4096 7月 30 19:40 /tmp/

会看到,/tmp目录的权限other部分为rwt,这个t就是我们设置的粘滞位

接下来,我们用其它用户创建两个文件:

[Jimmy@niesh tmp]$ touch test-file

[Jimmy@niesh tmp]$ mkdir test-dir

[Jimmy@niesh tmp]$ ll

总用量0

drwxrwxr-x.2 Jimmy Jimmy 6 7月 30 19:44 test-dir

-rw-rw-r--.1 root  Jimmy 07月30 19:44 test-file

切换到另外一个用户niesh:

[niesh@niesh tmp]$ ll

总用量 0

drwxrwxr-x. 2 Jimmy Jimmy 6 7月  30 19:44 test-dir

-rw-rw-r--. 1 root  Jimmy 0 7月  30 19:44 test-file

在 niesh用户下,删除/tmp目录下的文件:

[niesh@nieshtmp]$ rm -rf test-dir/ test-file

rm:无法删除"test-dir/": 不允许的操作

无法删除!

然后,我们切换到root,去掉/tmp的粘滞位:

[niesh@niesh tmp]$ su -

密码:

上一次登录:日7月3019:43:21CST2017pts/0上

[root@niesh ~]# chmod o-t /tmp/

[root@niesh ~]# ll -d /tmp/

drwxrwxrwx.9 root root 4096 7月30 19:48 /tmp/

最后,切换到普通用户niesh,再次删除/tmp下的文件:

[niesh@nieshroot]$ rm -rf/tmp/test-dir/ /tmp/test-file

[niesh@nieshroot]$ ll/tmp/

总用量0

你可能感兴趣的:(Linux文件权限与属性详解 之 SUID、SGID & SBIT)