Apabilities
- apabilities
- Linux Capabilities
- 线程的 capabilities
- Permitted 允许
- Effective 有效
- Inheritable
- Bounding
- Ambient
- 文件的 capabilities
- Permitted
- Inheritable
- Effective
- 运行 execve() 后 capabilities 的变化
- 案例分析
- 方法一、依次执行如下命令
- 方法二、iptables端口转发
- 方案三、赋予nginx监听80端口的能力
apabilities
Capabilities机制,是在Linux内核2.2之后引入的。它将root用户的权限细分为不同的领域,可以分别启用或禁用。从而,在实际进行特权操作时,如果euid不是root,便会检查是否具有该特权操作所对应的capabilities,并以此为依据,决定是否可以执行特权操作。
改变文件的所属者(chown()) | CAP_CHOWN |
---|---|
向进程发送信号(kill(), signal()) | CAP_KILL |
改变进程的uid(setuid(), setreuid(), setresuid()等) | CAP_SETUID |
trace进程(ptrace()) | CAP_SYS_PTRACE |
设置系统时间(settimeofday(), stime()等) | CAP_SYS_TIME |
Linux Capabilities
Capabilities
机制是在 Linux 内核 2.2
之后引入的,原理很简单,就是将之前与超级用户 root(UID=0)关联的特权细分为不同的功能组,Capabilites 作为线程(Linux 并不真正区分进程和线程)的属性存在,每个功能组都可以独立启用和禁用。其本质上就是将内核调用分门别类,具有相似功能的内核调用被分到同一组中。
这样一来,权限检查的过程就变成了:在执行特权操作时,如果线程的有效身份不是 root,就去检查其是否具有该特权操作所对应的 capabilities,并以此为依据,决定是否可以执行特权操作。
Capabilities 可以在进程执行时赋予,也可以直接从父进程继承。所以理论上如果给 nginx 可执行文件赋予了 CAP_NET_BIND_SERVICE
capabilities,那么它就能以普通用户运行并监听在 80 端口上。
capability 名称 | 描述 |
---|---|
CAP_AUDIT_CONTROL | 启用和禁用内核审计;改变审计过滤规则;检索审计状态和过滤规则 |
CAP_AUDIT_READ | 允许通过 multicast netlink 套接字读取审计日志 |
CAP_AUDIT_WRITE | 将记录写入内核审计日志 |
CAP_BLOCK_SUSPEND | 使用可以阻止系统挂起的特性 |
CAP_CHOWN | 修改文件所有者的权限 |
CAP_DAC_OVERRIDE | 忽略文件的 DAC 访问限制 |
CAP_DAC_READ_SEARCH | 忽略文件读及目录搜索的 DAC 访问限制 |
CAP_FOWNER | 忽略文件属主 ID 必须和进程用户 ID 相匹配的限制 |
CAP_FSETID | 允许设置文件的 setuid 位 |
CAP_IPC_LOCK | 允许锁定共享内存片段 |
CAP_IPC_OWNER | 忽略 IPC 所有权检查 |
CAP_KILL | 允许对不属于自己的进程发送信号 |
CAP_LEASE | 允许修改文件锁的 FL_LEASE 标志 |
CAP_LINUX_IMMUTABLE | 允许修改文件的 IMMUTABLE 和 APPEND 属性标志 |
CAP_MAC_ADMIN | 允许 MAC 配置或状态更改 |
CAP_MAC_OVERRIDE | 忽略文件的 DAC 访问限制 |
CAP_MKNOD | 允许使用 mknod() 系统调用 |
CAP_NET_ADMIN | 允许执行网络管理任务 |
CAP_NET_BIND_SERVICE | 允许绑定到小于 1024 的端口 |
CAP_NET_BROADCAST | 允许网络广播和多播访问 |
CAP_NET_RAW | 允许使用原始套接字 |
CAP_SETGID | 允许改变进程的 GID |
CAP_SETFCAP | 允许为文件设置任意的 capabilities |
CAP_SETPCAP | 参考 capabilities man page |
CAP_SETUID | 允许改变进程的 UID |
CAP_SYS_ADMIN | 允许执行系统管理任务,如加载或卸载文件系统、设置磁盘配额等 |
CAP_SYS_BOOT | 允许重新启动系统 |
CAP_SYS_CHROOT | 允许使用 chroot() 系统调用 |
CAP_SYS_MODULE | 允许插入和删除内核模块 |
CAP_SYS_NICE | 允许提升优先级及设置其他进程的优先级 |
CAP_SYS_PACCT | 允许执行进程的 BSD 式审计 |
CAP_SYS_PTRACE | 允许跟踪任何进程 |
CAP_SYS_RAWIO | 允许直接访问 /devport、/dev/mem、/dev/kmem 及原始块设备 |
CAP_SYS_RESOURCE | 忽略资源限制 |
CAP_SYS_TIME | 允许改变系统时钟 |
CAP_SYS_TTY_CONFIG | 允许配置 TTY 设备 |
CAP_SYSLOG | 允许使用 syslog() 系统调用 |
CAP_WAKE_ALARM | 允许触发一些能唤醒系统的东西(比如 CLOCK_BOOTTIME_ALARM 计时器) |
线程的 capabilities
每一个线程,具有 5 个 capabilities 集合,每一个集合使用 64
位掩码来表示,显示为 16
进制格式。
- Permitted 允许
- Effective 有效
- Inheritable 继承
- Bounding 边界
- Ambient 氛围
Permitted 允许
定义了线程能够使用的 capabilities 的上限。它并不使用线程的 capabilities,而是作为一个规定。也就是说,线程可以通过系统调用 capset()
来从 Effective
或 Inheritable
集合中添加或删除 capability,前提是添加或删除的 capability 必须包含在 Permitted
集合中(其中 Bounding 集合也会有影响,具体参考下文)。 如果某个线程想向 Inheritable
集合中添加或删除 capability,首先它的 Effective
集合中得包含 CAP_SETPCAP
这个 capabiliy。
Effective 有效
内核检查线程是否可以进行特权操作时,检查的对象便是 Effective
集合。如之前所说,Permitted
集合定义了上限,线程可以删除 Effective 集合中的某 capability,随后在需要时,再从 Permitted 集合中恢复该 capability,以此达到临时禁用 capability 的功能。
Inheritable
当执行exec()
系统调用时,能够被新的可执行文件继承的 capabilities,被包含在 Inheritable
集合中。这里需要说明一下,包含在该集合中的 capabilities 并不会自动继承给新的可执行文件,即不会添加到新线程的 Effective
集合中,它只会影响新线程的 Permitted
集合。
Bounding
Bounding
集合是 -
集合的超集,如果某个 capability 不在 Bounding
集合中,即使它在 Permitted
集合中,该线程也不能将该 capability 添加到它的 Inheritable
集合中。
Bounding 集合的 capabilities 在执行 fork()
系统调用时会传递给子进程的 Bounding 集合,并且在执行 execve
系统调用后保持不变。
- 当线程运行时,不能向 Bounding 集合中添加 capabilities。
- 一旦某个 capability 被从 Bounding 集合中删除,便不能再添加回来。
- 将某个 capability 从 Bounding 集合中删除后,如果之前
Inherited
集合包含该 capability,将继续保留。但如果后续从Inheritable
集合中删除了该 capability,便不能再添加回来。
Ambient
Linux 4.3
内核新增了一个 capabilities 集合叫 Ambient
,用来弥补 Inheritable
的不足。Ambient
具有如下特性:
Permitted
和Inheritable
未设置的 capabilities,Ambient
也不能设置。- 当
Permitted
和Inheritable
关闭某权限(比如CAP_SYS_BOOT
)后,Ambient
也随之关闭对应权限。这样就确保了降低权限后子进程也会降低权限。 - 非特权用户如果在
Permitted
集合中有一个 capability,那么可以添加到Ambient
集合中(也有了A权限),这样它的子进程便可以在Ambient
、Permitted
和Effective
集合中获取这个 capability。现在不知道为什么也没关系,后面会通过具体的公式来告诉你。
Ambient
的好处显而易见,举个例子,如果你将 CAP_NET_ADMIN
添加到当前进程的 Ambient
集合中,它便可以通过 fork()
和 execve()
调用 shell 脚本来执行网络管理任务,因为 CAP_NET_ADMIN
会自动继承下去。
文件的 capabilities
文件的 capabilities 被保存在文件的扩展属性中。如果想修改这些属性,需要具有 CAP_SETFCAP
的 capability。文件与线程的 capabilities 共同决定了通过 execve()
运行该文件后的线程的 capabilities。
文件的 capabilities 功能,需要文件系统的支持。如果文件系统使用了 nouuid
选项进行挂载,那么文件的 capabilities 将会被忽略。
类似于线程的 capabilities,文件的 capabilities 包含了 3 个集合:
- Permitted
- Inheritable
- Effective
这3个集合的具体含义如下:
Permitted
这个集合中包含的 capabilities,在文件被执行时,会与线程的 Bounding 集合计算交集,然后添加到线程的 Permitted
集合中。
Inheritable
这个集合与线程的 Inheritable
集合的交集,会被添加到执行完 execve()
后的线程的 Permitted
集合中。
Effective
这不是一个集合,仅仅是一个标志位。如果设置开启,那么在执行完 execve()
后,线程 Permitted
集合中的 capabilities 会自动添加到它的 Effective
集合中。对于一些旧的可执行文件,由于其不会调用 capabilities 相关函数设置自身的 Effective
集合,所以可以将可执行文件的 Effective bit 开启,从而可以将 Permitted
集合中的 capabilities 自动添加到 Effective
集合中。
运行 execve() 后 capabilities 的变化
我们用 P
代表执行 execve()
前线程的 capabilities,P'
代表执行 execve()
后线程的 capabilities,F
代表可执行文件的 capabilities。那么:
P’(ambient) = (file is privileged) ? 0 : P(ambient)
如果用户是 root 用户,那么执行 execve() 后线程的 Ambient 集合是空集;如果是普通用户,那么执行 execve() 后线程的 Ambient 集合将会继承执行 execve() 前线程的 Ambient 集合。
P’(permitted) = (P(inheritable) & F(inheritable)) |(F(permitted) & P(bounding))) |P’(ambient)
执行 execve() 前线程的 Inheritable 集合与可执行文件的 Inheritable 集合取交集,会被添加到执行 execve() 后线程的 Permitted 集合;可执行文件的 capability bounding 集合与可执行文件的 Permitted 集合取交集,也会被添加到执行 execve() 后线程的 Permitted 集合;同时执行 execve() 后线程的 Ambient 集合中的 capabilities 会被自动添加到该线程的 Permitted 集合中
P’(effective) = F(effective) ? P’(permitted) : P’(ambient)
如果可执行文件开启了 Effective 标志位,那么在执行完 execve() 后,线程 Permitted 集合中的 capabilities 会自动添加到它的 Effective 集合中。
P’(inheritable) = P(inheritable) [i.e., unchanged]
执行 execve() 前线程的 Inheritable 集合会继承给执行 execve() 后线程的 Inheritable 集合。
P’(bounding) = P(bounding) [i.e., unchanged]
案例分析
方法一、依次执行如下命令
cd /usr/local/nginx/sbin/
chown root nginx
chmod u+s nginx
优点是,方便简单
缺点是,这个set uid 最后也是让nginx运行在root权限下。 ps -ef |grep nginx 查看的时候,nginx的主进程是运行在root下的。 虽然是可以让普通用户运行nginx服务,但是不是所有nginx进程都在用户本身下运行
方法二、iptables端口转发
使用非80端口启动程序,然后再用iptables做一个端口转发。
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
(
sysctl -w net.ipv4.ip_forward=1
iptables -F -t nat
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to:8088
)
优点:可以用第三方用户直接启动,nginx的主进程就是用户本身来启动的
缺点:额外增加开销,负载低的情况可以,负载高了 就不太好了
方案三、赋予nginx监听80端口的能力
chown -R tang:tang /usr/local/nginx
# 改一下/usr/local/nginxde1所有者和所属组
setcap cap_net_bind_service=+eip nginx /usr/local/nginx/sbin
#这使得普通用户也能够做只有超级用户才能完成的工作
安装php,配合nginx
安装 PHP 和 PHP FPM 软件包:
yum install php php-cli php-fpm -y
检查服务状态,运行:
systemctl status php7.4-fpm
配置php-fpm
修改配置监听9000端口来处理nginx的请求
listen = 127.0.0.1:9000
修改Nginx配置文件
vim /usr/local/nginx/conf/nginx.conf
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi.conf;
}
重启一下nginx
然后访问http://192.168.137.131/index.php出现File not found错误处理
出现File not found错误处理,分两种情况:
1、php-fpm找不到SCRIPT_FILENAME里执行的php文件
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
改为
fastcgi_param SCRIPT_FILENAME d o c u m e n t r o o t document_rootdocument ootfastcgi_script_name;
然后再重启nginx:进入nginx可执行目录sbin下,输入命令./nginx -s reload 即可
2、php-fpm不能访问所执行的php,也就是权限问题
找到你的php-fpm的配置文件,找到下面这段,把apache替换成你要的用户组
RPM: apache Choosed to be able to access some dir as httpd user = www
RPM: Keep a group allowed to write in log dir. group = www
测试