问题标签 [linux-capabilities]

我处于一个困难的境地，我不知道一个进程需要哪些 linux 功能才能工作。最好的方法是什么，或者找出需要什么上限的任何方法？

我现在唯一能想到的就是使用 capsh 并将所有大写都放在一个进程上。然后该过程失败，我开始添加大写字母（通过删除--drop = CAP_XZY）直到它起作用。

有更好的建议吗？

尤其是在 Linux/POSIX 世界中，仅出于临时初始化目的（例如，读取 root 拥有的私钥文件，或打开一个小于 1024 的端口，或增加资源限制）需要一些 root 权限的守护进程，通常似乎遵循一种设计模式，他们使用setuid()/setresuid()和setgid()/之类的函数调用来更改其凭据setresgid()，然后调用fork()以将实际程序作为其子程序运行。据说fork()-ing 是“以防万一”完成的，但是这样做的实际安全考虑是什么？

并且跟进这一点，当（除了setgroups(0, NULL),setresgid(GID_NOBODY, GID_NOBODY, GID_NOBODY)和setresuid(UID_NOBODY, UID_NOBODY, UID_NOBODY)）程序还主动限制Linux 功能时，这个原因是否仍然相关，通过在不再需要时立即删除所有功能，通过调用cap_set_proc()?

我想知道是否有可能在没有 root 权限的情况下运行 Scapy 的 'sniff(...)'。

它用于捕获某些包的应用程序中。但我不想以 root 权限运行整个应用程序或更改 scapy 本身的任何内容。

提前致谢！

编辑：

对于测试，我使用以下代码：

我只能使用 sudo 运行它。

我试图用sudo setcap 'cap_net_admin=+eip' test.py. 但它没有显示任何效果。即使是all能力也无济于事。

我想CAP_NET_ADMIN在我的 python 应用程序中为某个子进程设置功能。我尝试了很多这样做，但我没有成功，因为没有可用的示例，这对我来说是可以理解的。

我所做的是prctl.capbset.drop("setgid", prctl.CAP_NET_ADMIN)在创建子进程之前按照建议使用 pip 安装了 python-prctl(1.6.1) 和 prctl(1.0.1) 并实施到我的应用程序中。不过，好像连capbset都认不出来了。

在子进程中，我想使用 scapy 嗅探网络。

运行我的应用程序如下：

sudo rkt run --insecure-options=image --interactive --net=host ./myapp.aci

我收到消息：

锁定内存失败：无法分配内存

经过一番挖掘，这似乎表明容器没有CAP_IPC_LOCK传递给它的能力。我已经深入研究了一些文档，但找不到我需要添加配置或任何选项来启用它的位置。我该怎么做呢？

如果我在特权模式下运行容器，它是否具有所有内核功能，还是我需要单独添加它们？

我正在尝试使一个使用原始套接字的程序以具有 Linux 功能的非 root 身份正确运行。程序如下：

如果我编译它并以非 root 身份运行它，我会得到一个错误，正如预期的那样：

如果我添加该cap_net_raw功能，作为有效且允许的功能，它就可以工作。

现在，我想使用pam_cap.so它来使只有特定用户才能使用 运行该程序cap_net_raw，而不是所有人。我/etc/security/capability.conf的是：

我/etc/pam.d/login的是（请注意，我也尝试过/etc/pam.d/sshd，但似乎也不起作用）：

我有一个 ssh 会话，然后我注销并重新登录并执行以下命令：

我的问题是：为什么我不能用 'socket' 程序执行cap_net_raw？我认为当我登录时，我的用户将获得它作为允许的功能，并且它将允许“用户”使用cap_net_raw.

这就是我正在运行的内容：

我在不同的主机上使用 Docker：RHEL7、SELS12 和 CentOS7，与在 SLES12 或 RHEL7 作为 Docker 主机上运行的容器相比，我发现在 CentOS7 上作为 Docker 主机运行的容器中存在不同的行为。

不同的行为与 Docker 容器中的常见问题有关： https ://github.com/docker/docker/issues/7147
https://github.com/docker/docker/issues/6800

在 CentOS7 作为 Docker 主机的容器中：

我有权解析路径中的符号：/proc/1
命令：ls -la /proc/1

容器的启动命令：

但在以 SLES12 或 RHEL7 作为 Docker 主机的容器中：

如您在上面的链接中所见，我使用相同的命令拒绝了许可。
命令：ls -la /proc/1

附加信息：

依赖于Docker 安全文档 ，容器默认以有限的 Linux 内核功能集开始。

其中一项功能是： CAP_SYS_PARCE
此功能默认存在于任何 Linux 主机

中： Linux 机器中的示例：

但是在所有容器中，默认情况下都缺少它（除非您使用 --cap-add=sys_ptrace 启动容器） 容器中的

示例： 您可以在此处看到容器具有一组受限制的功能，其中不包括 sys_ptrace 功能。

因此，如果我在 RHEL 或 SLES 中使用 --cap-add=sys_ptrace 作为 Docker 主机启动容器，我会得到与在 CentOS 7 中作为 Docker 主机相同的行为。

示例：Docker 主机：RHEL7
Docker 镜像：centos:latest（与之前相同）
Strat command: docker run -it --name=nessi_centos_test5 --cap-add=sys_ptrace centos:latest bash

正如您在此处看到的，为了获得与在 CentOS 7 中相同的行为，我需要使用额外的 sys_ptrace 功能启动我的容器。

技术信息：

1. 不同的 CentOS 7 行为：在容器中运行命令：
   ls -la /proc/1
   结果：没有错误
2. 其他主机（RHEL7 和 SLES12）的常规行为 在容器中运行命令：
   ls -la /proc/1
   结果：

ls: cannot read symbolic link /proc/1/cwd: Permission denied ls: cannot read symbolic link /proc/1/root: Permission denied ls: cannot read symbolic link /proc/1/exe: Permission denied

1. 不同的 CentOS 7 行为再现于：
   

[root@localhost 桌面]# uname -a
Linux localhost.localdomain 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[root@localhost Desktop]# docker info
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 1
Server Version: 1.11.2
Storage Driver: devicemapper
Pool Name: docker-253:0-136686025-pool
Pool Blocksize: 65.54 kB
基本设备大小：10.74 GB
支持文件系统：xfs
数据文件：/dev/loop0
元数据文件：/dev/loop1
使用的数据空间：324.3 MB
数据空间总计：107.4 GB
可用数据空间：35.43 GB
使用的元数据空间：847.9 kB
元数据空间总量：2.147 GB
元数据可用空间：2.147 GB
Udev 同步支持：true
启用
延迟删除：false 启用延迟删除：false
延迟删除设备计数：0
数据循环文件：/var/lib/docker/devicemapper/devicemapper/data
警告：强烈建议不要将环回设备用于生产用途。
使用--storage-opt dm.thinpooldev或使用--storage-opt <br>dm.no_warn_on_loop_devices=true来抑制此警告。
元数据循环文件：/var/lib/docker/devicemapper/devicemapper/metadata
库版本：1.02.107-RHEL7 (2016-06-09)
日志驱动程序：json-file
Cgroup 驱动程序：cgroupfs
插件：
卷：本地
网络：空主机bridge
内核版本：3.10.0-327.22.2.el7.x86_64
操作系统：CentOS Linux 7 (Core)
OSType：linux
架构：x86_64
CPU：1
总内存：993.3 MiB
名称：localhost.localdomain
ID：BPVJ:YDPR:4VUO:WNBN:DVZH:7MEH:TPMP:Y3MP:GMN7:UT36:LQ74:GJ4N
Docker 根目录：/var/lib/ docker
调试模式（客户端）：false
调试模式（服务器）：false
注册表：https
://index.docker.io/v1/ 警告：bridge-nf-call-iptables 已禁用
警告：bridge-nf-call-ip6tables 已禁用禁用

Docker 镜像：
centos:latest
ubuntu:14.04

也在：
Docker daemon 版本：1.10.2

2. 
   
   其他主机（RHEL7 和 SLES12） RHEL7 作为 Docker 主机的常规行为
   
   ： [root@localhost ~]# uname -a
   Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
   
   [root@localhost ~]# docker info
   Containers: 14
   Running: 6
   Paused: 0
   Stopped: 8
   Images: 22
   Server Version: 1.11.2
   Storage Driver: devicemapper
   Pool Name: docker-253:0 -67168288-pool
   池块大小：65.54 kB
   基本设备大小：10.74 GB
   支持文件系统：xfs
   数据文件：/dev/loop0
   元数据文件：/dev/loop1
   使用的数据空间：9.66 GB
   数据空间总计：107.4 GB
   可用数据空间：16.27 GB已
   使用元数据空间：7.68 MB
   元数据空间总计：2.147 GB
   可用元数据空间：2.14 GB
   支持 Udev 同步：true
   启用
   延迟删除：false 启用延迟删除：false
   延迟删除设备计数： 0
   数据循环文件：/var/lib/docker/devicemapper/devicemapper/data
   警告：强烈建议不要将环回设备用于生产用途。
   使用--storage-opt dm.thinpooldev或使用--storage-opt dm.no_warn_on_loop_devices=true来抑制此警告。
   元数据循环文件：/var/lib/docker/devicemapper/devicemapper/metadata
   库版本：1.02.107-RHEL7 (2015-12-01)
   日志驱动程序：json-file
   Cgroup 驱动程序：cgroupfs
   插件：
   卷：本地
   网络：空主机桥
   内核版本：3.10.0-123.el7.x86_64
   操作系统：Red Hat Enterprise Linux
   OSType：linux
   架构：x86_64
   CPU：2
   总内存：1.798 GiB
   名称：localhost .localdomain
   ID：VL2V:RUOZ:U55X:OCEQ:MAS6:MXYV:CKUY:WJQY:3KH3:LWPW:LUYH:E3MM
   Docker 根目录：/var/lib/docker
   调试模式（客户端）：false
   调试模式（服务器）： false
   注册表：https
   ://index.docker.io/v1/ 警告：bridge-nf-call-iptables 已禁用
   警告：bridge-nf-call-ip6tables 已禁用
   
   
   Docker 映像：
   centos:latest
   centos:7
   ubuntu:14.04
   ubuntu:latest
   rhel:latest
   suse/sles12:latest（在 SLES 机器上构建并复制到 RHEL 的映像）
   
   还在：
   Docker 守护程序版本：1.10.3 上进行了测试。1.9
   
   
   SLES12 作为 Docker 主机：
   
   

linux-ojix:~ # uname -a
Linux linux-ojix 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux

linux-ojix:~ # docker info
Containers: 6
Running: 3
Paused: 0
Stopped: 3
Images: 10
Server Version: 1.10.3

存储驱动程序：btrfs
构建版本：Btrfs v3.18.2+20150430
库版本：101
执行驱动程序：native-0.2
日志驱动程序：json-file
插件：
卷：本地
网络：bridge null host
内核版本：3.12.28-4-default
运行系统：SUSE Linux Enterprise Server 12
操作系统类型：linux
架构：x86_64
CPU：2
总内存：1.853 GiB
名称：linux-ojix
ID：NU4F:MOFR:RTUA:F2OM:4G67:NMGV:76S6:BONN:ASD5:XGHF:KVJQ: N242
警告：无交换限制支持


Docker 镜像：
centos:latest
centos:7
ubuntu:14.04
ubuntu:latest
suse/sles12:latest



有谁明白为什么 CentOS 作为 Docker 主机会导致不同的容器行为（容器中的 ls –la /proc/1 - 没有错误）与任何其他主机操作系统（容器中的 ls –la /proc/1 - 权限被拒绝错误）相比）？

我正在尝试为脚本提供 cap_net_bind_service Linux 功能。但是使用 setcap 似乎不起作用。

使用 sudo 仍然可以正常工作。

这是在 Fedora 23 工作站上。

在这一点上我有点迷茫，尝试关闭firewalld无效，并且无法弄清楚如何调试它。

容器实际启动后是否可以添加功能（例如：NET_ADMIN）？

几天前我启动了一个容器，它提供的服务正被其他几个在其他服务器上远程运行的进程使用。我需要为其添加一个环回接口，但不幸的是，我忘记了启动容器，--cap-add=NET_ADMIN因此现在无法添加接口。

我正在寻找一个选项，如果有可能以某种方式将此功能赋予此容器。