Linux DAC 权限管理详解
程序员文章站
2024-03-19 14:40:46
...
1. 背景简介
linux下有多种权限控制的机制，常见的如：DAC(Discretionary Access Control)自主式权限控制和MAC(Mandatory Access Control)强制访问控制。
其实本质上的模型都是差不多的，参与的对象有3种：主体(subject)、客体(object)、规则(policy)。
权限判定过程大概如下：
- 1、主体拥有自己的凭证来标识自己的身份。在DAC中，主体通常是进程，而凭证是进程对应用的euid和egid。
- 2、客体拥有属性来标识自己的身份。在DAC中，客体通常是文件，而权限相关属性是文件对应的uid和gid。
- 3、主体对客体的操作可以称之为行为。DAC的特点就是行为比较简单，行为仅包括R(读)、W(写)、X(执行)这三种。
- 4、针对"主体对客体发起的行为"，查询规则表来进行权限判定。DAC的UGO规则非常简单，把主体分为User、Group、Other三种类型，每种类型拥有自己的RWX mask。
DAC的权限控制策略是非常简洁，行为是简单的RWX三种，主体也很简单的就能被分为UGO三类。这种简洁造也就了DAC检查的开销非常小。
但是凡事都有好有坏，DAC的简洁造就了它的高效，但是过于简洁也让它的权限划分粒度过大，一旦获得了root权限，几乎就是无所不能。在CPU日益高涨的今天，性能开销已经不是问题了，权限的细粒度管理更加重要，所以诞生了MAC。MAC在DAC的基础上，把行为、规则、判定结果进一步细分。所以它的权限管理粒度更细，但是开销也稍大。
DAC是Linux权限管理的基础机制，我们本文的重点也是DAC。
2. 主体(subject)
2.1 用户
我们在权限管理的时候，通常做的第一件事就是创建群组(groupadd)、创建用户(useradd)。这些信息存储在以下的三个文件当中，其中最重要的信息就是UID、GID、密码。
/etc/passwd
每一行都表示的是一个用户的信息；一行有7个段位；每个段位用:号分割，例如：
beinan:x:500:500:beinan sun:/home/beinan:/bin/bash
linuxsir:x:501:502::/home/linuxsir:/bin/bash
第一字段：用户名（也被称为登录名）；在上面的例子中，我们看到这两个用户的用户名分别是 beinan 和linuxsir；
第二字段：口令；在例子中我们看到的是一个x，其实密码已被映射到/etc/shadow 文件中；
第三字段：UID ；请参看本文的UID的解说；
第四字段：GID；请参看本文的GID的解说；
第五字段：用户名全称，这是可选的，可以不设置，在beinan这个用户中，用户的全称是beinan sun ；而linuxsir 这个用户是没有设置全称；
第六字段：用户的家目录所在位置；beinan 这个用户是/home/beinan ，而linuxsir 这个用户是/home/linuxsir ；
第七字段：用户所用SHELL 的类型，beinan和linuxsir 都用的是 bash ；所以设置为/bin/bash ；
useradd 会把新用户的主组设置为 /etc/default/useradd 中 GROUP 变量指定的值，再或者默认是 100。
/etc/group
/etc/group 的内容包括用户组（Group）、用户组口令、GID及该用户组所包含的用户（User），每个用户组一条记录；格式如下：
group_name:passwd:GID:user_list
在/etc/group 中的每条记录分四个字段：
第一字段：用户组名称；
第二字段：用户组密码；
第三字段：GID
第四字段：用户列表，每个用户之间用,号分割；本字段可以为空；如果字段为空表示用户组为GID的用户名；
我们举个例子：
root:x:0:root,linuxsir
注：用户组root，x是密码段，表示没有设置密码，GID是0,root用户组下包括root、linuxsir以及GID为0的其它用户（可以通过/etc/passwd查看）；；
/etc/shadow
/etc/shadow 文件的内容包括9个段位，每个段位之间用:号分割；我们以如下的例子说明:
beinan:$1$VE.Mq2Xf$2c9Qi7EQ9JP8GKF8gH7PB1:13072:0:99999:7:::
linuxsir:$1$IPDvUhXP$8R6J/VtPXvLyXxhLWPrnt/:13072:0:99999:7::13108:
第一字段：用户名（也被称为登录名），在/etc/shadow中，用户名和/etc/passwd 是相同的，这样就把passwd 和shadow中用的用户记录联系在一起；这个字段是非空的；
第二字段：密码（已被加密），如果是有些用户在这段是x，表示这个用户不能登录到系统；这个字段是非空的；
第三字段：上次修改口令的时间；这个时间是从1970年01月01日算起到最近一次修改口令的时间间隔（天数），您可以通过passwd 来修改用户的密码，然后查看/etc/shadow中此字段的变化；
第四字段：两次修改口令间隔最少的天数；如果设置为0,则禁用此功能；也就是说用户必须经过多少天才能修改其口令；此项功能用处不是太大；默认值是通过/etc/login.defs文件定义中获取，PASS_MIN_DAYS 中有定义；
第五字段：两次修改口令间隔最多的天数；这个能增强管理员管理用户口令的时效性，应该说在增强了系统的安全性；如果是系统默认值，是在添加用户时由/etc/login.defs文件定义中获取，在PASS_MAX_DAYS 中定义；
第六字段：提前多少天警告用户口令将过期；当用户登录系统后，系统登录程序提醒用户口令将要作废；如果是系统默认值，是在添加用户时由/etc/login.defs文件定义中获取，在PASS_WARN_AGE 中定义；
第七字段：在口令过期之后多少天禁用此用户；此字段表示用户口令作废多少天后，系统会禁用此用户，也就是说系统会不能再让此用户登录，也不会提示用户过期，是完全禁用；
第八字段：用户过期日期；此字段指定了用户作废的天数（从1970年的1月1日开始的天数），如果这个字段的值为空，帐号永久可用；
第九字段：保留字段，目前为空，以备将来Linux发展之用；
2.2 进程
我们在讲Linux权限管理的时候经常讲到用户，但是内核中却没有用户这个数据结构。内核中只会识别UID，至于用户名是通过在/etc/passwd文件中查找对应关系得到的。
以下是获取uid，并且根据uid查找到对应文件名的实例：
// test.c:
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <pwd.h>
int main()
{
uid_t userid;
struct passwd* pwd;
userid=getuid(); // 使用系统调用获取到当前进程的uid
printf("userid is %d\n",userid);
pwd=getpwuid(userid); // 根据uid查找`/etc/passwd`文件，得到对应的用户名和用户目录
printf("username is %s\nuserdir is %s\n",pwd->pw_name,pwd->pw_dir);
}
// 对应输出：
$ ./test
userid is 1000
username is ipu
userdir is /home/ipu
$ cat /etc/passwd
...
ipu:x:1000:1000:ipu:/home/ipu:/bin/bash
权限管理时真正代表用户的是进程，操作文件的也是进程，也就是说用户所拥有的文件访问权限是通过进程来体现的。
2.2.1 凭证(credentials)
用户拥有的权限，是通过进程的credentials成员来描述的。
task_stuct结构体包含credentials的定义：
struct task_struct {
...
/* Process credentials: */
/* Tracer's credentials at attach: */
/* ptrace时attach的tracer的证书 */
const struct cred __rcu *ptracer_cred;
/* Objective and real subjective task credentials (COW): */
/* `客体`和`实际主体`的进程证书 */
const struct cred __rcu *real_cred;
/* Effective (overridable) subjective task credentials (COW): */
/* `有效的主体`(可覆盖)的进程证书 */
const struct cred __rcu *cred;
...
}
对DAC来说，最重要的就是struct cred中的uid、gid定义:
/*
* The security context of a task
*
* The parts of the context break down into two categories:
*
* (1) The objective context of a task. These parts are used when some other
* task is attempting to affect this one.
*
* (2) The subjective context. These details are used when the task is acting
* upon another object, be that a file, a task, a key or whatever.
*
* Note that some members of this structure belong to both categories - the
* LSM security pointer for instance.
*
* A task has two security pointers. task->real_cred points to the objective
* context that defines that task's actual details. The objective part of this
* context is used whenever that task is acted upon.
*
* task->cred points to the subjective context that defines the details of how
* that task is going to act upon another object. This may be overridden
* temporarily to point to another security context, but normally points to the
* same context as task->real_cred.
*/
/ *
* 进程的安全上下文
*
* 上下文的内部分为两类：
* （1）进程的`客体`上下文。当某些其他进程试图影响本进程时，将使用这些部分。
* （2）`主体`上下文。当进程作用于另一个对象（文件、进程、键或其他对象）时，将使用这些详细信息。
*
* 请注意，此结构体的某些成员同时属于这两个类别 - 例如LSM安全指针。
*
* 一个进程有两个安全指针：
* 1、`task->real_cred`指向`客体`上下文，它定义了进程的实际细节。每当该进程被其他人作用时，都会使用此上下文的客观部分。
* 2、`task->cred`指向`主体`上下文，该上下文定义了该任务将如何作用于另一个对象的详细信息。可能会暂时覆盖它以指向另一个安全上下文，但通常指向与task->real_cred相同的上下文。
* /
struct cred {
atomic_t usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
atomic_t subscribers; /* number of processes subscribed */
void *put_addr;
unsigned magic;
#define CRED_MAGIC 0x43736564
#define CRED_MAGIC_DEAD 0x44656144
#endif
kuid_t uid; /* real UID of the task */
kgid_t gid; /* real GID of the task */
kuid_t suid; /* saved UID of the task */
kgid_t sgid; /* saved GID of the task */
kuid_t euid; /* effective UID of the task */
kgid_t egid; /* effective GID of the task */
kuid_t fsuid; /* UID for VFS ops */
kgid_t fsgid; /* GID for VFS ops */
unsigned securebits; /* SUID-less security management */
kernel_cap_t cap_inheritable; /* caps our children can inherit */
kernel_cap_t cap_permitted; /* caps we're permitted */
kernel_cap_t cap_effective; /* caps we can actually use */
kernel_cap_t cap_bset; /* capability bounding set */
kernel_cap_t cap_ambient; /* Ambient capability set */
#ifdef CONFIG_KEYS
unsigned char jit_keyring; /* default keyring to attach requested
* keys to */
struct key __rcu *session_keyring; /* keyring inherited over fork */
struct key *process_keyring; /* keyring private to this process */
struct key *thread_keyring; /* keyring private to this thread */
struct key *request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
void *security; /* subjective LSM security */
#endif
struct user_struct *user; /* real user ID subscription */
struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
struct group_info *group_info; /* supplementary groups for euid/fsgid */
struct rcu_head rcu; /* RCU deletion hook */
};
// objective ：本译客观，这里可翻译成客体。在本进程作被其他进程作用时，称为客体。
// subjective ：本译主观，这里可翻译成主体。本进程作为主体时，作用于其他客体(如 文件、进程、键或其他对象)。
2.2.2 uid/suid/euid/fsuid
仔细看cred结构，其中最令人疑惑的是uid/gid有四种表达方式，这其中的区别在哪里呢？
| name | meaning | descript |
|---|---|---|
| uid | real UID | 进程原本的uid |
| suid | saved UID | 一个uid缓存 在SUID机制设置euid时，suid同时被设置成euid 在setuid()设置uid时，suid同时被设置成uid |
| euid | effective UID | 有效uid，权限判断时看的就是euid。 初始状态时，uid和euid相同，做一些权限切换时euid可能改变不等于uid了。 |
| fsuid | UID for VFS ops | linux系统中特有的文件操作uid，通常情况下和euid相等。 除非调用setfsuid()设置成不一样 |
2.2.3 初始uid (fork())
uid的初始状态是在进程创建时，复制父进程的安全凭证:
_do_fork() → copy_process() → copy_creds():
int copy_creds(struct task_struct *p, unsigned long clone_flags)
{
/* (1) 分配新的cred，并复制当前进程cred的内容 */
new = prepare_creds();
/* (2) 赋值给新建进程 */
p->cred = p->real_cred = get_cred(new);
}
普通进程在初始状态时，uid/suid/euid/fsuid都是相同的。
2.2.4 uid权限升级 (SUID execve())
在linux日常使用时，一般我们使用普通用户来操作，bash进程是普通用户的uid，那么各种操作创建出来的新进程也是普通用户uid。
某些情况下，需要切换到root操作，使用su或者sudo命令输入对应密码就能切换到root用户权限。这种权限升级的操作是什么原理呢？
权限的升级依赖于SUID(set-user-id)机制，在文件的UGO策略中除了记录三组用户的rwx mask位，还针对x权限定义了一个补充的s位，对应UGO用户分别为SUID/SGID/SBIT。如果文件设置了SUID，那么它在执行的时候，会把进程的权限(euid)设置成文件属主的uid。我们查看sudo/su文件就是SUID被设置：
[[email protected] uid]$ ll /bin/sudo
---s--x--x. 1 root root 147320 Aug 9 2019 /bin/sudo
[[email protected] uid]$ ll /bin/su
-rwsr-xr-x. 1 root root 32128 Aug 9 2019 /bin/su
这个SUID机制就是专门为提升/切换用户权限而设计的，切换用户也必须先提升到root用户才能切换到其他用户。在这类文件被执行后，不需要验证密码，进程的euid被设置成文件属主的uid，如果文件属主是root用户当前进程就有了root权限，同时这时进程的uid和euid也不相等了。
具体的execve()代码解析如下：
do_execve() → do_execveat_common():
step 1、分配一份新的安全凭证：
→ prepare_bprm_creds() → prepare_exec_creds()
step 2.1、根据被执行文件是否有suid/sgid被职位，来使用文件属主uid/gid替代进程原来的uid/gid
→ prepare_binprm() → bprm_fill_uid()
static void bprm_fill_uid(struct linux_binprm *bprm)
{
struct inode *inode;
unsigned int mode;
kuid_t uid;
kgid_t gid;
/*
* Since this can be called multiple times (via prepare_binprm),
* we must clear any previous work done when setting set[ug]id
* bits from any earlier bprm->file uses (for example when run
* first for a setuid script then again for its interpreter).
*/
bprm->cred->euid = current_euid();
bprm->cred->egid = current_egid();
/* (2.1.1) 如果path不支持suid则返回 */
if (path_nosuid(&bprm->file->f_path))
return;
if (task_no_new_privs(current))
return;
inode = bprm->file->f_path.dentry->d_inode;
mode = READ_ONCE(inode->i_mode);
if (!(mode & (S_ISUID|S_ISGID)))
return;
/* Be careful if suid/sgid is set */
inode_lock(inode);
/* reload atomically mode/uid/gid now that lock held */
/* (2.1.2) 从文件inode读出对应的mode、uid、gid */
mode = inode->i_mode;
uid = inode->i_uid;
gid = inode->i_gid;
inode_unlock(inode);
/* We ignore suid/sgid if there are no mappings for them in the ns */
if (!kuid_has_mapping(bprm->cred->user_ns, uid) ||
!kgid_has_mapping(bprm->cred->user_ns, gid))
return;
/* (2.1.3) 如果suid标志被设置，使用文件属主uid替代进程原来的euid */
if (mode & S_ISUID) {
bprm->per_clear |= PER_CLEAR_ON_SETID;
bprm->cred->euid = uid;
}
/* (2.1.4) 如果sgid和group的x属性被设置，使用文件属主gid替代进程原来的egid */
if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
bprm->per_clear |= PER_CLEAR_ON_SETID;
bprm->cred->egid = gid;
}
}
step 2.2、
→ prepare_bprm_creds() → security_bprm_set_creds() → cap_bprm_set_creds()
int cap_bprm_set_creds(struct linux_binprm *bprm)
{
/* (2.2.1) 把suid和fsuid同步成euid的值 */
new->suid = new->fsuid = new->euid;
new->sgid = new->fsgid = new->egid;
}
step 3、更新进程为新的安全凭证：
→ load_elf_binary() → install_exec_creds() → commit_creds()
注意：可以看到SUID的权限是非常大的，如果文件属主是root，不需要验证密码进程权限被提升为root权限。这类文件如果有漏洞的话，就会被攻击获取到root权限，需要特别小心。
2.2.5 uid权限降级 (setreuid()/setuid()/setresuid()/setfsuid())
在使用sudo/su进行操作时，并不希望进程一直处于root权限当中，它最终会根据配置切换到适当的权限。
例如sudo -u test cat /etc/shadow的命令执行过程：
- 1、首先因为
sudo的SUID被设置且文件属主为root，execve()执行sudo，进程权限被切换成root权限。 - 2、接下来sudo进程运行在root权限状态，来验证当前用户密码。
- 3、如果密码验证成功，则读取
/etc/sudoers配置文件，其中规定了当前用户使用sudo命令时的权限。/etc/sudoers文件中的配置格式如下%wheel ALL=(ALL) ALL，规定了指定用户能切换到哪些用户，能运行哪些命令。 - 4、如果当前用户允许切换到
test用户，则执行sudo命令的-u test参数，调用setuid()系统调用把当前进程的euid切换成test用户。 - 5、切换到
test用户以后，如果/etc/sudoers允许执行cat命令，则继续执行cat /etc/shadow命令。
从上述的过程可以看到权限切换的关键途径，一般通过SUID机制来无密码的把权限升级到root，然后在root状态下验证用户密码，再根据配置通过setreuid()/setuid()/setresuid()系统调用到权限降级到合适用户。
setreuid()/setuid()/setresuid()系统调用可以降级权限，它没有升级的能力。它的几个基本准则是：
这几个系统调用的详细解析过程：
SYSCALL_DEFINE1(setuid, uid_t, uid)
{
struct user_namespace *ns = current_user_ns();
const struct cred *old;
struct cred *new;
int retval;
kuid_t kuid;
/* (1) 在当前namespace下，把uid转换成kuid */
kuid = make_kuid(ns, uid);
if (!uid_valid(kuid))
return -EINVAL;
/* (2) 分配新的进程权限凭证，默认拷贝了旧的凭证值 */
new = prepare_creds();
if (!new)
return -ENOMEM;
old = current_cred();
retval = -EPERM;
/* (3.1) 如果当前进程有CAP_SETUID权限的能力 (一般这里指root权限，在通过SUID切换到root权限时，会赋予用户所有能力)
设置新cred的suid和uid为传入参数uid
*/
if (ns_capable(old->user_ns, CAP_SETUID)) {
new->suid = new->uid = kuid;
if (!uid_eq(kuid, old->uid)) {
retval = set_user(new);
if (retval < 0)
goto error;
}
/* (3.2) 如果当前进程没有CAP_SETUID(不是root用户)，设置的uid也不等于原cred的uid或suid中的一个
出错返回
*/
} else if (!uid_eq(kuid, old->uid) && !uid_eq(kuid, new->suid)) {
goto error;
}
/* (3.3) 综合上述逻辑分为几种情况：
1、有CAP_SETUID权限(root用户)，把新cred的uid、suid、euid、fsuid全都设置成新的uid
2、没有CAP_SETUID权限(非root用户)，只能把新cred的euid、fsuid设置成原cred的uid或suid中的一个。例如原来使用SUID机制切换了权限，这里也可以切换回去。
3、不符合以上两种条件的都是非法操作。
*/
new->fsuid = new->euid = kuid;
/* (4) lsm check点 */
retval = security_task_fix_setuid(new, old, LSM_SETID_ID);
if (retval < 0)
goto error;
/* (5) 更新为新凭证 */
return commit_creds(new);
error:
abort_creds(new);
return retval;
}
SYSCALL_DEFINE2(setreuid, uid_t, ruid, uid_t, euid)
{
struct user_namespace *ns = current_user_ns();
const struct cred *old;
struct cred *new;
int retval;
kuid_t kruid, keuid;
kruid = make_kuid(ns, ruid);
keuid = make_kuid(ns, euid);
if ((ruid != (uid_t) -1) && !uid_valid(kruid))
return -EINVAL;
if ((euid != (uid_t) -1) && !uid_valid(keuid))
return -EINVAL;
new = prepare_creds();
if (!new)
return -ENOMEM;
old = current_cred();
retval = -EPERM;
/* (1.1) 如果传入ruid != -1，则更新新cred的uid值
否则保持新cred的uid值不变
*/
if (ruid != (uid_t) -1) {
new->uid = kruid;
/* (1.2) 如果ruid != -1，还需要满足以下附加条件，才能更新新cred的uid值：
1、有CAP_SETUID权限(root用户)，可以把uid设置成任意值。
2、没有CAP_SETUID权限(非root用户)，只能把uid设置成原cred的uid或euid中的任一个。
*/
if (!uid_eq(old->uid, kruid) &&
!uid_eq(old->euid, kruid) &&
!ns_capable(old->user_ns, CAP_SETUID))
goto error;
}
/* (2.1) 如果传入euid != -1，则更新新cred的euid值
否则保持新cred的euid值不变
*/
if (euid != (uid_t) -1) {
new->euid = keuid;
/* (2.2) 如果euid != -1，还需要满足以下附加条件，才能更新新cred的euid值：
1、有CAP_SETUID权限(root用户)，可以把euid设置成任意值。
2、没有CAP_SETUID权限(非root用户)，只能把euid设置成原cred的uid、euid或suid中的任一个。
*/
if (!uid_eq(old->uid, keuid) &&
!uid_eq(old->euid, keuid) &&
!uid_eq(old->suid, keuid) &&
!ns_capable(old->user_ns, CAP_SETUID))
goto error;
}
if (!uid_eq(new->uid, old->uid)) {
retval = set_user(new);
if (retval < 0)
goto error;
}
/* (3) 如果ruid被成功更新，
或者euid被成功更新，且euid不等于原uid的值
更新suid的值为euid
*/
if (ruid != (uid_t) -1 ||
(euid != (uid_t) -1 && !uid_eq(keuid, old->uid)))
new->suid = new->euid;
/* (4) 同步更新fsuid为euid (linux下，大部分情况下fsuid就等于euid) */
new->fsuid = new->euid;
retval = security_task_fix_setuid(new, old, LSM_SETID_RE);
if (retval < 0)
goto error;
return commit_creds(new);
error:
abort_creds(new);
return retval;
}
SYSCALL_DEFINE3(setresuid, uid_t, ruid, uid_t, euid, uid_t, suid)
{
struct user_namespace *ns = current_user_ns();
const struct cred *old;
struct cred *new;
int retval;
kuid_t kruid, keuid, ksuid;
kruid = make_kuid(ns, ruid);
keuid = make_kuid(ns, euid);
ksuid = make_kuid(ns, suid);
if ((ruid != (uid_t) -1) && !uid_valid(kruid))
return -EINVAL;
if ((euid != (uid_t) -1) && !uid_valid(keuid))
return -EINVAL;
if ((suid != (uid_t) -1) && !uid_valid(ksuid))
return -EINVAL;
new = prepare_creds();
if (!new)
return -ENOMEM;
old = current_cred();
retval = -EPERM;
/* (1.1) 有CAP_SETUID权限(root用户)，可以把uid/euid/suid设置成任意值。 */
if (!ns_capable(old->user_ns, CAP_SETUID)) {
/* (1.2) 如果传入ruid != -1，没有CAP_SETUID权限(非root用户)，只能把uid设置成原cred的uid、euid或suid中的任一个。 */
if (ruid != (uid_t) -1 && !uid_eq(kruid, old->uid) &&
!uid_eq(kruid, old->euid) && !uid_eq(kruid, old->suid))
goto error;
/* (1.3) 如果传入euid != -1，没有CAP_SETUID权限(非root用户)，只能把euid设置成原cred的uid、euid或suid中的任一个。 */
if (euid != (uid_t) -1 && !uid_eq(keuid, old->uid) &&
!uid_eq(keuid, old->euid) && !uid_eq(keuid, old->suid))
goto error;
/* (1.4) 如果传入suid != -1，没有CAP_SETUID权限(非root用户)，只能把suid设置成原cred的uid、euid或suid中的任一个。 */
if (suid != (uid_t) -1 && !uid_eq(ksuid, old->uid) &&
!uid_eq(ksuid, old->euid) && !uid_eq(ksuid, old->suid))
goto error;
}
/* (2.1) 更新uid的值为传入的ruid */
if (ruid != (uid_t) -1) {
new->uid = kruid;
if (!uid_eq(kruid, old->uid)) {
retval = set_user(new);
if (retval < 0)
goto error;
}
}
/* (2.2) 更新euid的值为传入的euid */
if (euid != (uid_t) -1)
new->euid = keuid;
/* (2.3) 更新suid的值为传入的suid */
if (suid != (uid_t) -1)
new->suid = ksuid;
/* (3) 同步更新fsuid为euid (linux下，大部分情况下fsuid就等于euid) */
new->fsuid = new->euid;
retval = security_task_fix_setuid(new, old, LSM_SETID_RES);
if (retval < 0)
goto error;
return commit_creds(new);
error:
abort_creds(new);
return retval;
}
SYSCALL_DEFINE1(setfsuid, uid_t, uid)
{
const struct cred *old;
struct cred *new;
uid_t old_fsuid;
kuid_t kuid;
old = current_cred();
old_fsuid = from_kuid_munged(old->user_ns, old->fsuid);
kuid = make_kuid(old->user_ns, uid);
if (!uid_valid(kuid))
return old_fsuid;
new = prepare_creds();
if (!new)
return old_fsuid;
/* (1) 符合以下条件，把当前进程fsuid设置成传入的uid
情况1、有CAP_SETUID权限(root用户)。
情况2、没有CAP_SETUID权限(非root用户)，且传入的uid等于原uid/suid/euid中的任意一员。
*/
if (uid_eq(kuid, old->uid) || uid_eq(kuid, old->euid) ||
uid_eq(kuid, old->suid) || uid_eq(kuid, old->fsuid) ||
ns_capable(old->user_ns, CAP_SETUID)) {
if (!uid_eq(kuid, old->fsuid)) {
new->fsuid = kuid;
if (security_task_fix_setuid(new, old, LSM_SETID_FS) == 0)
goto change_okay;
}
}
abort_creds(new);
return old_fsuid;
change_okay:
commit_creds(new);
return old_fsuid;
}
3. 客体(object)
对DAC模式来说，客体通常是文件。但是进程也是可以作为客体的，还记得进程有两个cred成员，task->cred是进程作为主体时的权限凭证，而task->real_cred是进程作为客体时的权限凭证。
对客体文件来说，最重要的属性是文件的属主uid和gid：
inode->i_uid
inode->i_gid
对应命令查看时的：
需要注意的是进程主体(subject)也是和文件耦合在一起，一是进程的执行代码是从文件中加载的，而是SUID机制能把进程的执行权限修改成文件属主。所以在DAC模型理解时，注意相互之间的概念，避免绕晕。
4. 规则(policy)
对DAC模式来说，规则通常比较简单，一般就存储在客体文件inode相关属性中。而MAC模式，规则比较复杂，需要独立的文件来存储。
4.1 UGO(User、Ggroup、Other)规则
UGO是最通用的规则了，客体文件inode->i_mode中存储了UGO 3组mask，每组mask由rwx三个行为组成。
UGO把操作当前文件的进程分为3种类型：
- User用户。文件的属主，即主体进程的euid等于客体文件的uid。
- Group同组用户。即主体进程的egid等于客体文件的gid。
- Other用户。不满足上述两种条件的其他用户。
每组用户对当前文件的行为，又分为3种权限：
- r(Read，读取)：
对文件而言，具有读取文件内容的权限；
对目录来说，具有浏览目录的权限。 - w(Write,写入)：
对文件而言，具有新增,修改,删除文件内容的权限；
对目录来说，具有新建，删除，修改，移动目录内文件的权限。 - x(eXecute，执行)：
对文件而言，具有执行文件的权限；
对目录了来说该用户具有进入目录的权限。
目录权限的总结：
- 1、目录的只读访问不允许使用cd进入目录，必须要有执行的权限才能进入。
- 2、只有执行权限只能进入目录，不能看到目录下的内容，要想看到目录下的文件名和目录名，需要可读权限。
- 3、一个文件能不能被删除，主要看该文件所在的目录对用户是否具有写权限，如果目录对用户没有写权限，则该目录下的所有文件都不能被删除，文件所有者除外
- 4、目录的w位不设置，即使你拥有目录中某文件的w权限也不能写该文件
文件默认权限：umask值用于设置用户在创建文件时的默认权限，当我们在系统中创建目录或文件时，目录或文件所具有的默认权限就是由umask值决定的。对于root用户，系统默认的umask值是
0022；对于普通用户，系统默认的umask值是0002。执行umask命令可以查看当前用户的umask值。
umask值一共有4组数字，其中第1组数字用于定义特殊权限，我们一般不予考虑，与一般权限有关的是后3组数字。
默认情况下，对于目录，用户所能拥有的最大权限是777；对于文件，用户所能拥有的最大权限是目录的最大权限去掉执行权限，即666。因为x执行权限对于目录是必须的，没有执行权限就无法进入目录，而对于文件则不必默认赋予x执行权限。
对于root用户，他的umask值是022。当root用户创建目录时，默认的权限就是用最大权限777去掉相应位置的umask值权限，即对于所有者不必去掉任何权限，对于所属组要去掉w权限，对于其他用户也要去掉w权限，所以目录的默认权限就是755；当root用户创建文件时，默认的权限则是用最大权限666去掉相应位置的umask值，即文件的默认权限是644。
有了UGO规则，主体进程在RWX客体文件时会做对应的权限规则检查。例如，open一个文件时，几个权限校验的关键节点：
- 第一步权限检查： 最开始对文件所在路径上每个目录项对应的inode进行执行权限检查.对应代码：path_openat->link_path_walk->may_lookup->inode_permission;
- 第二步权限检查：如果是新建文件，对文件所在目录项的inode做写和可执行权限检查。对应代码：path_openat->do_last->lookup_open->vfs_create->may_create->inode_permission.
- 第三步权限检查：真正打开文件之前，对文件所对应的inode做读写权限检查。对应代码：path_openat->do_last->may_open->inode_permission.
inode_permission()最后会调用acl_permission_check()来做UGO规则检查：
inode_permission() → __inode_permission() → do_inode_permission() → generic_permission() → acl_permission_check()
static int acl_permission_check(struct inode *inode, int mask)
{
/* (1) 从i_mode中取出UGO规则 */
unsigned int mode = inode->i_mode;
/* (2) User用户取最高3bit规则，主体进程的euid等于客体文件的uid */
if (likely(uid_eq(current_fsuid(), inode->i_uid)))
mode >>= 6;
else {
/* (3) User用户匹配失败首先去匹配ACL规则 */
if (IS_POSIXACL(inode) && (mode & S_IRWXG)) {
int error = check_acl(inode, mask);
if (error != -EAGAIN)
return error;
}
/* (4) ACL匹配失败则尝试匹配Group用户规则，
Group用户取中间3bit规则，主体进程的egid等于客体文件的gid
*/
if (in_group_p(inode->i_gid))
mode >>= 3;
}
/* (5) 如果以上条件都未匹配成功，则为Other用户，取最低3bit规则 */
/*
* If the DACs are ok we don't need any capability check.
*/
/* (6) 使用规则允许的3bit和当前操作进行匹配，决定放行还是拒绝 */
if ((mask & ~mode & (MAY_READ | MAY_WRITE | MAY_EXEC)) == 0)
return 0;
return -EACCES;
}
4.2 ACL(Access Control List)规则
UGO的规则非常简洁和实用，但是在使用的过程中人们发现这个分组粒度实在是太粗了，仅仅3种分组UGO。如果一个用户需要在UGO之外分配一个独有的权限，该怎么操作呢？
在普通权限中，用户对文件只有三种身份，就是属主、属组和其他人；每种用户身份拥有读（read）、写（write）和执行（execute）三种权限。但是在实际工作中，这三种身份实在是不够用。ACL 权限就是为了解决这个问题的。在使用 ACL 权限给用户 st 陚予权限时，st 既不是 /project 目录的属主，也不是属组，仅仅赋予用户 st 针对此目录的 r-x 权限。这有些类似于 Windows 系统中分配权限的方式，单独指定用户并单独分配权限，这样就解决了用户身份不足的问题。ACL是Access Control List（访问控制列表）的缩写，不过在Linux系统中，ACL用于设定用户针对文件的权限，而不是在交换路由器中用来控制数据访问的功能（类似于防火墙）。
ACL主要是以下两条命令：
# getfacl 文件名 // 查看ACL权限
# setfacl 选项 文件名 // 设定ACL权限
选项：
-m：设定 ACL 权限。如果是给予用户 ACL 权限，则使用"u:用户名：权限"格式赋予；如果是给予组 ACL 权限，则使用"g:组名：权限" 格式赋予；
-x：删除指定的 ACL 权限；
-b：删除所有的 ACL 权限；
-d：设定默认 ACL 权限。只对目录生效，指目录中新建立的文件拥有此默认权限；
-k：删除默认 ACL 权限；
-R：递归设定 ACL 权限。指设定的 ACL 权限会对目录下的所有子文件生效；
例如：我们要求root是/project目录的属主，权限是rwx；tgroup是此目录的属组，tgroup组中拥有班级学员zhangsan和lisi，权限是rwx；其他人的权限是0。这时试听学员st来了，她的权限是r-x。我们来看具体的分配命令。
[[email protected] ~]# useradd zhangsan
[[email protected] ~]# useradd lisi
[[email protected] ~]# useradd st
[[email protected] ~]# groupadd tgroup
// 添加需要试验的用户和用户组，省略设定密码的过程
[[email protected] ~]# mkdir /project #建立需要分配权限的目录
[[email protected] ~]# chown root:tgroup /project/
// 改变/project目录的属主和属组
[[email protected] ~]# chmod 770 /project/
// 指定/project目录的权限
[[email protected] ~]# ll -d /project/
drwxrwx--- 2 root tgroup 4096 1月19 04:21 /project/
// 查看一下权限，已经符合要求了
// 这时st学员来试听了，如何给她分配权限
[[email protected] ~]# setfacl -m u:st:rx /project/
// 给用户st赋予r-x权限，使用"u:用户名：权限" 格式
[[email protected] /]# cd /
[[email protected] /]# ll -d project/
drwxrwx---+ 3 root tgroup 4096 1月19 05:20 project/
// 使用ls-l査询时会发现，在权限位后面多了一个"+"，表示此目录拥有ACL权限
[[email protected] /]# getfacl project
// 查看/prpject目录的ACL权限
#file: project <-文件名
#owner: root <-文件的属主
#group: tgroup <-文件的属组
user::rwx <-用户名栏是空的，说明是属主的权限
user:st:r-x <-用户st的权限
group::rwx <-组名栏是空的，说明是属组的权限
mask::rwx <-mask权限
other::--- <-其他人的权限
// 大家可以看到，st 用户既不是 /prpject 目录的属主、属组，也不是其他人，我们单独给 st 用户分配了 r-x 权限。这样分配权限太方便了，完全不用先辛苦地规划用户身份了。
ACL规则是UGO规则的补充，相当于扩充了UGO用户组，但是操作的行为RWX还是不能扩充。
ACL规则信息保存在inode当中。例如：Ext4 扩展属性（xattrs）通常存储在磁盘上的一个单独的数据块中，通过inode.i_file_acl*引用。扩展属性的第一应用是存储文件的ACL以及其他安全数据(selinux)。
在上一节acl_permission_check()的分析中我们就已经看到，在User用户匹配失败后就去匹配ACL规则，在ACL规则匹配失败以后才去匹配Group用户。我们看看具体的过程：
inode_permission() → __inode_permission() → do_inode_permission() → generic_permission() → acl_permission_check() → check_acl()：
static int check_acl(struct inode *inode, int mask)
{
#ifdef CONFIG_FS_POSIX_ACL
struct posix_acl *acl;
if (mask & MAY_NOT_BLOCK) {
acl = get_cached_acl_rcu(inode, ACL_TYPE_ACCESS);
if (!acl)
return -EAGAIN;
/* no ->get_acl() calls in RCU mode... */
if (is_uncached_acl(acl))
return -ECHILD;
return posix_acl_permission(inode, acl, mask & ~MAY_NOT_BLOCK);
}
/* (1) 获取到acl信息 */
acl = get_acl(inode, ACL_TYPE_ACCESS);
if (IS_ERR(acl))
return PTR_ERR(acl);
if (acl) {
/* (2) 查询主体进程在ACL规则中的权限 */
int error = posix_acl_permission(inode, acl, mask);
posix_acl_release(acl);
return error;
}
#endif
return -EAGAIN;
}
4.3 Capability规则
在UGO的使用过程中，人们还发现UGO的另一个弊端，就是行为的划分也是粗粒度的，仅仅三种行为RWX。这样会造成权限过量的情况，如果用户只需要某项行为的权限，但是你只能给他root的rwx权限，那他就拥有了所有其他行为的root rwx权限。这种拥有所有root权限的程序是攻击的首选目标，如果它有漏洞就会造成系统门户大开。
Linux引入了capabilities机制对root行为进行细粒度的控制，实现按需授权，从而减小系统的安全攻击面。
例如，把ping的权限从SUID的root权限，降为普通用户+cap_net_admin,cap_net_raw能力，功能上完全一致，但是安全风险大大降低。
-
step 1、因为 ping 命令在执行时需要访问网络，这就需要获得 root 权限，常规的做法是通过 SUID 实现的(和 passwd 命令相同)。红框中的 s 说明应用程序文件被设置了 SUID，这样普通用户就可以执行这些命令了。
-
step 2、移除 ping 命令文件上的 SUID 权限。在移除 SUID 权限后，普通用户在执行 ping 命令时碰到了 “ping: socket: Operation not permitted” 错误。
-
step 3、为 ping 命令文件添加 capabilities。通过 setcap 命令可以添加执行 ping 命令所需的 capabilities 为 cap_net_admin 和 cap_net_raw，被赋予合适的 capabilities 后，ping 命令又可以正常工作了，相比 SUID 它只具有必要的特权，在最大程度上减小了系统的安全攻击面。
Linux 将传统上与超级用户 root 关联的特权划分为不同的单元，称为 capabilites。Capabilites 作为线程(Linux 并不真正区分进程和线程)的属性存在，每个单元可以独立启用和禁用。如此一来，权限检查的过程就变成了：在执行特权操作时，如果进程的有效身份不是 root，就去检查是否具有该特权操作所对应的 capabilites，并以此决定是否可以进行该特权操作。比如要向进程发送信号(kill())，就得具有 capability CAP_KILL；如果设置系统时间，就得具有 capability CAP_SYS_TIME。
capabilities能力的全集可以参考capabilities man page。
在主体进程的credentials结构体中，定义了本进程的capability能力：
struct cred {
...
kernel_cap_t cap_inheritable; /* caps our children can inherit */
kernel_cap_t cap_permitted; /* caps we're permitted */
kernel_cap_t cap_effective; /* caps we can actually use */
kernel_cap_t cap_bset; /* capability bounding set */
kernel_cap_t cap_ambient; /* Ambient capability set */
...
}
和SUID机制一样，在文件执行的时候，把文件的capability和当前进程的capability进行综合：
do_execve() → do_execveat_common()→ prepare_bprm_creds() → security_bprm_set_creds() → cap_bprm_set_creds()：
int cap_bprm_set_creds(struct linux_binprm *bprm)
{
const struct cred *old = current_cred();
struct cred *new = bprm->cred;
bool effective = false, has_fcap = false, is_setid;
int ret;
kuid_t root_uid;
if (WARN_ON(!cap_ambient_invariant_ok(old)))
return -EPERM;
ret = get_file_caps(bprm, &effective, &has_fcap);
if (ret < 0)
return ret;
/* (1) root uid等于0 */
root_uid = make_kuid(new->user_ns, 0);
/* (2) 判断当前进程是不是root用户，针对root权限的capability能力赋值 */
handle_privileged_root(bprm, has_fcap, &effective, root_uid);
/* (3) 普通用户的capability综合过程，就没有仔细分析了 */
/* if we have fs caps, clear dangerous personality flags */
if (__cap_gained(permitted, new, old))
bprm->per_clear |= PER_CLEAR_ON_SETID;
/* Don't let someone trace a set[ug]id/setpcap binary with the revised
* credentials unless they have the appropriate permit.
*
* In addition, if NO_NEW_PRIVS, then ensure we get no new privs.
*/
is_setid = __is_setuid(new, old) || __is_setgid(new, old);
if ((is_setid || __cap_gained(permitted, new, old)) &&
((bprm->unsafe & ~LSM_UNSAFE_PTRACE) ||
!ptracer_capable(current, new->user_ns))) {
/* downgrade; they get no more than they had, and maybe less */
if (!ns_capable(new->user_ns, CAP_SETUID) ||
(bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS)) {
new->euid = new->uid;
new->egid = new->gid;
}
new->cap_permitted = cap_intersect(new->cap_permitted,
old->cap_permitted);
}
new->suid = new->fsuid = new->euid;
new->sgid = new->fsgid = new->egid;
/* File caps or setid cancels ambient. */
if (has_fcap || is_setid)
cap_clear(new->cap_ambient);
/*
* Now that we've computed pA', update pP' to give:
* pP' = (X & fP) | (pI & fI) | pA'
*/
new->cap_permitted = cap_combine(new->cap_permitted, new->cap_ambient);
/*
* Set pE' = (fE ? pP' : pA'). Because pA' is zero if fE is set,
* this is the same as pE' = (fE ? pP' : 0) | pA'.
*/
if (effective)
new->cap_effective = new->cap_permitted;
else
new->cap_effective = new->cap_ambient;
if (WARN_ON(!cap_ambient_invariant_ok(new)))
return -EPERM;
if (nonroot_raised_pE(new, old, root_uid, has_fcap)) {
ret = audit_log_bprm_fcaps(bprm, new, old);
if (ret < 0)
return ret;
}
new->securebits &= ~issecure_mask(SECURE_KEEP_CAPS);
if (WARN_ON(!cap_ambient_invariant_ok(new)))
return -EPERM;
/* Check for privilege-elevated exec. */
bprm->cap_elevated = 0;
if (is_setid ||
(!__is_real(root_uid, new) &&
(effective ||
__cap_grew(permitted, ambient, new))))
bprm->cap_elevated = 1;
return 0;
}
↓
static void handle_privileged_root(struct linux_binprm *bprm, bool has_fcap,
bool *effective, kuid_t root_uid)
{
const struct cred *old = current_cred();
struct cred *new = bprm->cred;
if (!root_privileged())
return;
/*
* If the legacy file capability is set, then don't set privs
* for a setuid root binary run by a non-root user. Do set it
* for a root user just to cause least surprise to an admin.
*/
if (has_fcap && __is_suid(root_uid, new)) {
warn_setuid_and_fcaps_mixed(bprm->filename);
return;
}
/*
* To support inheritance of root-permissions and suid-root
* executables under compatibility mode, we override the
* capability sets for the file.
*/
/* (2.1) 如果当前进程的euid或者uid等于root用户0
则给进程赋值所有capability (cap_bset成员的值包含了capability全集，所有bit都为1)
*/
if (__is_eff(root_uid, new) || __is_real(root_uid, new)) {
/* pP' = (cap_bset & ~0) | (pI & ~0) */
new->cap_permitted = cap_combine(old->cap_bset,
old->cap_inheritable);
}
/*
* If only the real uid is 0, we do not set the effective bit.
*/
if (__is_eff(root_uid, new))
*effective = true;
}
在权限判断时，如果UGO权限匹配拒绝，继续尝试进行capability的匹配：
inode_permission() → __inode_permission() → do_inode_permission() → generic_permission():
int generic_permission(struct inode *inode, int mask)
{
int ret;
/*
* Do the basic permission checks.
*/
/* (1) 首先进行UGO权限匹配，如果失败则尝试进行capability能力匹配 */
ret = acl_permission_check(inode, mask);
if (ret != -EACCES)
return ret;
if (S_ISDIR(inode->i_mode)) {
/* DACs are overridable for directories */
if (!(mask & MAY_WRITE))
/* (2.1) 尝试进行CAP_DAC_READ_SEARCH能力匹配 */
if (capable_wrt_inode_uidgid(inode,
CAP_DAC_READ_SEARCH))
return 0;
/* (2.2) 尝试进行CAP_DAC_OVERRIDE能力匹配 */
if (capable_wrt_inode_uidgid(inode, CAP_DAC_OVERRIDE))
return 0;
return -EACCES;
}
/*
* Searching includes executable on directories, else just read.
*/
mask &= MAY_READ | MAY_WRITE | MAY_EXEC;
if (mask == MAY_READ)
/* (2.3) 尝试进行CAP_DAC_READ_SEARCH能力匹配 */
if (capable_wrt_inode_uidgid(inode, CAP_DAC_READ_SEARCH))
return 0;
/*
* Read/write DACs are always overridable.
* Executable DACs are overridable when there is
* at least one exec bit set.
*/
if (!(mask & MAY_EXEC) || (inode->i_mode & S_IXUGO))
/* (2.4) 尝试进行CAP_DAC_OVERRIDE能力匹配 */
if (capable_wrt_inode_uidgid(inode, CAP_DAC_OVERRIDE))
return 0;
return -EACCES;
}
4.4 selinux规则
综合上述的规则来说，在UGO使用的过程中，大家越来越发现了UGO的弊端就是权限划分的粒度过粗。为了解决这个问题，ACL和Capability从不同的角度尝试解决这个问题：
- ACL尝试扩充UGO的用户组。把3组扩充成自定义多组。
- Capability尝试扩充RWX行为。把3组行为扩充成多组行为。
在这之后，selinux综合了ACL和Capability的扩展思路，推出了一套完成的扩充用户组和行为的细粒度权限管理方案。
后续我们再来详细分析selinux的实现。
5. 提权漏洞及防护
5.1 内核漏洞提权
利用内核的漏洞，直接修改运行进程的euid的值，用来获取root权限。例如：CVE-2017-16995、CVE-2018-1000001、CVE-2016-5195。
这种漏洞的防护分为几步：
- step 1、在程序execve()执行时记录进程的uid/suid/euid/fsuid初始值。在LSM钩子security_bprm_committed_creds()上记录：
do_execve() → do_execveat_common() → exec_binprm() → load_elf_binary() → install_exec_creds() → security_bprm_committed_creds()
- step 2、在更改uid的合法途径，这几个系统调用(setreuid()/setuid()/setresuid()/setfsuid())中判断uid有没有被非法修改，合法则记录改动。在LSM钩子security_task_fix_setuid()上记录：
setreuid()/setuid()/setresuid()/setfsuid() → security_task_fix_setuid()
- step 3、在各个关键路径上，比较当前的uid值和初始值，如果合法途径不可能做到，则为非法提权：
有两条简单的规则来进行判断：
1、如果execve()初始的uid或者euid的值为0则表明进程有root权限，则当前uid/suid/euid/fsuid为任意值都是合法的，因为root用户有这种能力。
2、如果execve()初始的uid或者euid的值不为0则表明进程没有root权限，则当前的uid/suid/euid/fsuid值只能为初始值uid或euid的其中一种。因为合法途径setreuid()/setuid()/setresuid()/setfsuid()只能在有限范围内改动。
5.2 sudo漏洞提权
CVE-2019-14287，对于sudoer中配置的非root权限用户，使用"sudo #-1"漏洞获得了root权限。
该漏洞的防护，可以在setresuid()系统调用中做pre钩子，如果普通用户传入-1参数则进行拦截。
参考资料：
1、Linux 用户身份与进程权限
2、Linux 特殊权限 SUID,SGID,SBIT
3、linux内核open过程的权限管理
4、Linux Capabilities 简介
5、linux权限检查机制
6、inode权限检查
7、linux内核setuid分析
8、setuid seteuid setreuid 三个函数讲解
9、Linux Capabilities 入门：让普通进程获得 root 的洪荒之力
10、UID, EUID, SUID, FSUID
推荐阅读