capabilities: ambient capabilities说明

linux capability介绍

最早之前,linux对任务权限分为privileged processes(UID等于0,属于超级用户或者root用户)和unprivileged processes(UID非0)。privileged processes拥有系统的所有权限,而unprivileged processes拥有部分权限(根据进程凭证,比如effective UID, effective GID,and supplementary group list)。

Linux自2.2版本以后,加入了capabilities功能,将这些特权分为不同的种类,比如

  • CAP_KILL:拥有kill进程的权限
  • CAP_SETFCAP:拥有配置文件capabulities属性的权限
  • CAP_SYS_BOOT:运行reboot和kexec_load的权限
  • CAP_SYS_MODULE:模块相关操作的权限

(更多介绍:参考文档3中“Capabilities list”介绍)
内核细分的这些权限,不再根据超级用户/普通用户来划分归属,而是可以由用户自由配置(配置还是要超级用户权限滴),即使普通用户也可以做某些之前超级用户才可以执行的任务(比如reboot)。同时capabilities可以细分到线程,支持子进程或者创建线程继承capabilities属性。

每个线程拥有四个capability sets:
(1)Permitted(pP):规定该线程的capabilities能力的全集,即表示线程能够使用的能力的集合。它并不使能线程的capabilities,而是作为一个规定。
(2)Effective(pE):使能该线程的capabilities能力。当线程进行某个特权操作时,系统会检查effective对应位是否有效。如有效,则允许执行。
(3)Inheritable(pI):线程通过execve(2) 执行新命令时,新命令集成的capabilities能力。
(4)bounding set(X):关闭线程的capabilities能力。(此项在capabilities的man文档中并未和上面三个并列,但是在patch中提及,属于capabilitiy sets一员)

举例来说,
某线程设置Permitted:CAP_KILL,CAP_SETFCAP和CAP_SYS_BOOT,那么此线程最大能拥有这些权限。
如果想让它拥有重启系统的权限(CAP_SYS_BOOT),那么Effective设置CAP_SYS_BOOT即可(另外两项可以不设置)。如果想要拥有Permitted定义以外的权限,比如CAP_WAKE_ALARM ,那么Effective会设置失败。
如果希望execve(2)执行新的命令有重启系统权限,那么设置Inheritable:CAP_SYS_BOOT即可。
(更多介绍:参考文档3中“Thread capability sets”介绍)

同时文件也可以拥有capabilities权限,Permitted(fP),Effective(fE)和Inheritable(fI)。
使用execve(2)执行的新命令继承权限遵循:

        pP' = (X & fP) | (pI & fI)   
        pI' = pI
        pE' = (fE ? pP' : 0) 
       X is unchanged

where:

       P         denotes the value of a thread capability set before the
                 execve(2)

       P'        denotes the value of a thread capability set after the
                 execve(2)

       F         denotes a file capability set

       cap_bset  is the value of the capability bounding set (described
                 below).

解读:
pP’ = (X & fP) | (pI & fI)
execve(2)执行新任务的P’(permitted),是基于fP&X(总集-bounding未使能)与pI & fI(线程和文件属性inheritable取与,inheritable表示子任务应该拥有的capabilities)的取或。

pI’ = pI
execve(2)执行新任务的P’(inheritable),继承原任务的P(inheritable)

pE’ = (fE ? pP’ : 0)
execve(2)执行新任务的P’(effective),根据F(effective)
(文件effective是否设置),设置则继承新任务的P’(permitted),否则无capabilities(即新任务未使能任何权限,但是还是可以根据pP’再调用cap_set使能)。

以上更多介绍,可以见:参考文档3和参考文档4。

内核capabilities机制存在的问题

1.引入管理混乱。举例来说如果非特权进程设置fE后,它将遵循“secure exec”规则:AT_SECURE被设置后,LD_PRELOAD就不会生效;
2.安全问题。给非特权进程提供特权用户的某些权限,这样增加了黑客攻击的通道。黑客很可能利用capabilities里面漏洞进行提权操作。
3.inheritance是基本无用的。如果你非特权用户或者二进制文件,并且fI未使能时,此时意味着你无法通过execve(2)执行一个帮助程序或者超出权限的命令。同时一般来说,我们希望进程包括创建的子进程拥有同样的权限,此时经常被设置成pP’ = pI。但是这样的话,你又要考虑每个非特权进程的权限问题等等。

ambient capabilities

linux4.3内核新增了一种capability mask,“ambient”(pA)。pA完成了用户对pI的不足。

pA具有如下特性:
(1)pP和pI未设置的capabilities,pA也不能设置,即pA不能使能超出pP&pI的特权;
(2)当pP或者pI某权限(比如CAP_SYS_BOOT权限)关闭后,pA也随之关闭对应权限,这样确保降低权限时候,子任务可以同时降低;
(3)当使用setresuid将用户从特权用户切换到非特权用户时,pA将被清除(设置SECBIT_NO_SETUID_FIXUP后不会被清除);

权限规则被修改成:

           pA' = (file caps or setuid or setgid ? 0 : pA)
           pP' = (X & fP) | (pI & fI) | pA'
           pI' = pI   pE' = (fE ? pP' : pA')
           X is unchanged

非特权用户如果有一个capability,那么可以添加到pA。如果这样做,那么它子进程可以在pA,pP和pE中获取这种能力。举例来说,如果你设置pA = CAP_NET_BIND_SERVICE,那么你子进程可以自动连接到low-bumbered ports。

linux对应commit提供了测试用例,ambient_test.c

/*
 * Test program for the ambient capabilities. This program spawns a shell
 * that allows running processes with a defined set of capabilities.
 *
 * (C) 2015 Christoph Lameter 
 * Released under: GPL v3 or later.
 *
 *
 * Compile using:
 *
 *  gcc -o ambient_test ambient_test.o -lcap-ng
 *
 * This program must have the following capabilities to run properly:
 * Permissions for CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE
 *
 * A command to equip the binary with the right caps is:
 *
 *  setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test
 *
 *
 * To get a shell with additional caps that can be inherited by other processes:
 *
 *  ./ambient_test /bin/bash
 *
 *
 * Verifying that it works:
 *
 * From the bash spawed by ambient_test run
 *
 *  cat /proc/$$/status
 *
 * and have a look at the capabilities.
 */

#include 
#include 
#include 
#include 
#include 
#include 

/*
 * Definitions from the kernel header files. These are going to be removed
 * when the /usr/include files have these defined.
 */
#define PR_CAP_AMBIENT 47
#define PR_CAP_AMBIENT_IS_SET 1
#define PR_CAP_AMBIENT_RAISE 2
#define PR_CAP_AMBIENT_LOWER 3
#define PR_CAP_AMBIENT_CLEAR_ALL 4

static void set_ambient_cap(int cap)
{
    int rc;

    capng_get_caps_process();
    rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap);
    if (rc) {
        printf("Cannot add inheritable cap\n");
        exit(2);
    }
    capng_apply(CAPNG_SELECT_CAPS);

    /* Note the two 0s at the end. Kernel checks for these */
    if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0)) {
        perror("Cannot set cap");
        exit(1);
    }
}

int main(int argc, char **argv)
{
    int rc;

    set_ambient_cap(CAP_NET_RAW);
    set_ambient_cap(CAP_NET_ADMIN);
    set_ambient_cap(CAP_SYS_NICE);

    printf("Ambient_test forking shell\n");
    if (execv(argv[1], argv + 1))
        perror("Cannot exec");

    return 0;
}

编译执行:

#gcc -o ambient_test ambient_test.c -lcap-ng
(-lcap-ng使用时cap-ng.h: No such file or directory错误,请 sudo apt-get install libcap-ng-dev)
#sudo setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test
#./ambient_test /bin/bash
#cat /proc/$$/status

CapInh: 0000000000803000
CapPrm: 0000000000803000
CapEff: 0000000000803000
CapBnd: 0000003fffffffff
CapAmb: 0000000000803000  
CapAmb表示ambient特性,此时execv进入的新的shell环境,pI,pP和pE集成原来的pA。

参考文档:
(1) https://lwn.net/Articles/632520/
(2) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
(3) http://man7.org/linux/man-pages/man7/capabilities.7.html
(4) https://www.cnblogs.com/iamfy/archive/2012/09/20/2694977.html
capabilities: ambient capabilities说明_第1张图片

你可能感兴趣的:(linux)