如何在不丢失基于文件系统的功能的情况下执行流程，保留功能？

Question

我想在没有setuid，文件“+ p”功能的情况下使系统可用，并且通常没有在设置PR_SET_NO_NEW_PRIVS时禁用的内容。

使用这种方法（init设置PR_SET_NO_NEW_PRIVS并且基于文件系统的能力提升不再可能）你不能“重新填充”你的能力，只需要小心不要“泼溅”它们。

如何execve其他一些过程没有“泼溅”任何已授权的功能（例如新程序的文件是setcap =ei）？只是“我相信这个新过程，因为我相信自己”。例如，一个功能被赋予用户（并且用户想要在他开始的任何程序中运用它）......

我可以永久地制作整个文件系统=ei吗？我想保持文件系统不干扰该方案，不能授予或撤销功能;通过父母 - >儿童事物控制一切。

Answer 1

我并不是说我建议你这样做，但现在就是这样。

从手册中摘录，有一些变化。根据它： -- src/modules ---- module1 -------- static ---- module2 -------- static 不会改变能力。而且现在在Linux内核4.3中添加了一个环境集，这似乎是你想要做的。

fork

Answer 2

如果您参考功能“手册页：

，目前没有简单的方法可以做到这一点

During an execve(2), the kernel calculates the new capabilities of the process
using the following algorithm:

P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0 

P'(inheritable) = P(inheritable)    [i.e., unchanged]

where:

P        denotes the value of a thread capability set before the execve(2)
P'       denotes the value of a capability set after the execve(2)
F        denotes a file capability set
cap_bset is the value of the capability bounding set 

如果您要执行的文件没有设置其fP位，或者未设置其fI位，则您的进程将不允许，因此没有有效的功能。

设置整个文件系统允许和继承位在技术上是可行的，但这没有多大意义，因为它会大大降低系统的安全性，（编辑：正如你所提到的那样，对新的可执行文件不起作用）

你确实可以通过pam_cap为用户提供一些功能，但你不能让他们执行他们刚刚使用它编译的任何文件。设计功能是为了给程序而不是用户提供动力，你可以在Hallyn's paper中阅读：

  

一个关键的洞察力是观察程序，而不是人，运动   特权。也就是说，在计算机中完成的所有操作都是通过   代理 - 程序 - 只有这些程序知道如何处理   他们可以信任特权来使用它。

另请参阅定义POSIX功能的POSIX draft 1003.1e，第310页：

  

建立流程链也是不合适的（a   单个过程中的程序序列）一组功能   在整个链条的生命周期中保持固定和活跃。 [...]   这是最小特权原则的应用，它   同样适用于用户和流程。

有人要求在最近的this Linux内核邮件列表（2012年12月）中介绍您想要做的功能，并且给出了一些非常有趣的答案。有些人认为，在exec中删除继承规则中的文件功能会引入一些安全问题，而且这些功能并不是针对这样的功能而设计的，即使没有给出解释会引入哪个安全问题：/

目前唯一的方法是修改Linux内核中继承功能的方式（2个文件要修改，我在3.7内核上成功测试过），但不清楚是否有安全保护，如上所述上方。

在旧内核（2.6.33之前）上有一个没有文件功能的编译选项（CONFIG_SECURITY_FILE_CAPABILITIES），但是我怀疑使用这样一个旧内核是你的选择。

Answer 3

我认为（我的理解），使用功能的最佳方式是：

• 对于需要功能且受信任的程序，包括受信任的不泄漏功能：例如Wire-shark的数据包嗅探部分，一个需要在端口80上侦听的Web服务器。
  • 新程序，功能意识：设置允许。
  • 遗留程序，而非功能感知：设置允许且有效
• 对于会泄漏功能的程序，并且具有可以（有时）使用功能的代码：set inherited
  • e.g。对于chmod set，继承CA​​P_FOWNER，如果用户需要超级权限（通常由root持有的那些），那么他们需要使用setpriv（或等效的，这可以归入sudo），否则它可以在非特权模式下工作。
• 当进程需要分叉并共享某些功能时，然后才使用环境。可能相同的可执行文件;如果它是一个不同的，那么这个新的将允许或继承文件上的set。 [编辑：我刚刚意识到，如果你不执行，你不需要环境。如果我想一个环境用例，在设置良好的系统中，我会在这里添加它。当没有在可以使用它的文件上设置继承时，Ambient可以用作过渡机制。]

环境的使用：

• 在文件没有正确功能的系统上。 （过渡技术）。
• 对于shell脚本，它们不具备功能（因为它们不能具有setuid），除非在已修复的系统上，然后在脚本上允许setuid。
• 在此处添加更多内容。