一旦*nix 系统被正确配置和强化,是否可以想象删除所有超级用户/root 用户的策略?完全从系统中删除 root 以完全防止超级用户权限提升漏洞是否有好处?
编辑:更重要的是:超级用户(root、uid=0 或其他)可以完全替换为基于功能的系统吗?
一旦*nix 系统被正确配置和强化,是否可以想象删除所有超级用户/root 用户的策略?完全从系统中删除 root 以完全防止超级用户权限提升漏洞是否有好处?
编辑:更重要的是:超级用户(root、uid=0 或其他)可以完全替换为基于功能的系统吗?
即使您愿意,我认为您也无法删除 root 用户。来自维基百科:
例如,在类 Unix 系统上,用户标识符 (UID) 为零的用户是超级用户,无论该帐户的名称如何。
漏洞利用的许多内核代码都做了类似的事情
// become root
uid = 0;
...
if (uid == 0)
// do some protected thing
所以超级用户并不是真正的“用户帐户”,它实际上是数字 0。如果你能找到一个可以设置的漏洞,uid = 0
那么 bam!sudo
无论是否有名为“root”的用户帐户,您的进程都有。
编辑地址评论:几种风格的 linux 在前面加上“!” 到/etc/shadow
密码文件中的 root 的密码(不能使用密码散列函数生成的字符),这使得实际上无法以 root 身份登录。这阻止了基于破解 root 密码的某些类型的 root 权限升级攻击,但更危险的权限升级类型是基于缓冲区溢出攻击,该攻击将进程的uid
变量覆盖uid=0
为 ,此时该进程是根。
正如其他人所说,“删除”根 UID(在 UNIX 上表示为 UID 0)是没有意义的。我会更进一步说,将系统冻结为无法提供新特权是没有意义的。请注意,此答案非常固执且含糊,因为要涵盖的主题非常庞大。让我们先来看看在 *NIX 上作为 root 意味着什么。我要评论一下 Linux,因为它是最流行的 *NIX 并且它带有特定的方法。希望其他人可以涵盖 BSD 系列。让我们区分一下 root 在上下文中的含义:
请注意,在任何情况下,在系统范围内盲目地将权限限制应用于当前以 root 身份运行的所有二进制文件是绝对没有意义的。通常这些特权的存在是有原因的。因此,您应该阅读下面的摘要,解释如何影响您为非特权用户运行的特定服务,以及您希望保护它们免受利用。
访问 *NIX 系统上的文件的大多数权限是由 DAC 模型规定的。许多内核接口和 IPC 机制被抽象为文件,因此这是一个相当重要的考虑因素。这是具有所有者 ID、组 ID 和所有者、组成员和其他身份的读/写/执行权限的模型。它还带有 suid 和 sgid 位,但我暂时不使用这些。
默认情况下,UID 0 总是绕过 DAC 检查。这是因为 UID 0 具有 CAP_DAC_OVERRIDE UNIX 功能(见下文)。自行删除此功能的进程必须遵守 DAC,尽管您的发行版上的大多数系统文件无论如何都由 root 拥有和写入。删除此功能可能会在一定程度上保护用户文件,但不会保护系统本身。没有这种能力(并且没有获得其他能力的直接手段)的 root 用户也很可能会修改 logind、您的内核映像或其他关键文件,以破坏或接管您的系统。
除了 DAC 检查之外,Linux 上的所有系统调用都通过实现Linux 安全模块接口的可插入内核模块。这些可用于拒绝root权限。
例如,SELinux 为此使用了角色的概念。在我知道的所有发行版的默认策略中,您的登录守护程序将以有限的角色打开您的根会话,并且您需要显式切换到调用的角色,sysadm_r
然后才能执行大多数传统的根操作。您确实需要编写策略以防止 root 与其他角色类似 root。尽管如此,由于 LSM 允许您编写强制访问控制策略,因此您可以通过这种方式有效地限制 root 权限。然而,好的方面是您可以有效地将 user:role 元组捕获到他们的角色中,并且您可以根据登录方式有选择地提供角色。这将允许在系统范围内限制特定 root 帐户的范围。
我不想解释有关功能的手册页,但本质上,功能允许用户身份与内核的特定接口进行交互。例如,CAP_CHOWN 允许您修改文件的所有者。默认情况下,root 启用了大多数功能(如果我没记错的话,CAP_MAC_ADMIN
或者CAP_MAC_OVERRIDE
默认情况下未启用),而其他身份则没有。
但是,您可以从自己的集合中删除一些功能,因此您可以作为根进程将自己转换为非特权进程,只要您具有这些CAP_SET_FCAP
和CAP_SET_PCAP
功能。请注意,有人认为可以使用许多其他功能来重新获得完全权限。我现在找不到此类功能的列表,但您应该意识到您需要认真考虑如何利用您留给根进程的功能来进一步妥协。
虽然 DAC 控制文件访问,但功能可以说控制系统调用访问和行为(MAC LSM 控制两者)。您必须阅读许多调用的手册才能了解每个功能的作用。
有人批评 Linux 功能的适用性。Kerrisk 在“CAP_SYS_ADMIN: the new root”中辩称,某些功能非常依赖于拥有它们意味着拥有完整的权力。这表明您不能完全摆脱超级用户的概念。您至少需要拥有极高的特权才能启动和设置您的系统,并提供某些内核内服务。在提供强大限制机会的 MAC 系统中,您经常会遇到需要重新获得特权的问题(例如,在 SELinux 上,您可能需要将角色更改为sysadm_r
执行维护操作)。同样,如果您摆脱了这些功能,您是否能够(重新)启动新的特权服务?这样做的能力不等于完全享有特权吗?
命名空间允许您非常模糊地为在其中运行的进程提供系统的不同视图。您可以使用挂载命名空间来更改进程及其子进程可以查看和修改的文件,或者使用网络命名空间来提供不同的网络接口和系统配置。例如,这对于提供 PaaS 服务的人很有用。用户命名空间允许您将命名空间内的所有用户身份映射到外部的单个用户身份。这意味着您可以拥有一个具有根用户的子系统,该用户可以在命名空间内做任何想做的事情,并且映射到命名空间外的非特权用户。
那到底有什么意义呢?如果有人在您的内核上使用了允许他们升级为 root 的漏洞,那么用户命名空间的好处就没有实际意义。但是,如果漏洞利用针对的是 suid 二进制文件,那么在其命名空间内获得 root 权限的非特权进程仍然无法影响主机操作系统。请注意,诸如命名空间之类的限制解决方案只会改变您的防御边界。您必须证明命名空间内的完全特权进程不能通过您在主机操作系统和命名空间之间保持开放的通信通道影响主机操作系统,而不是证明您的所有特权进程都完美无缺且无法被利用。最终,如果您需要命名空间内的特权服务来访问资源,那么损害该服务将授予对该资源的访问权限。
上述所有这些方法都允许您将服务限制为特定权限(并带有特定警告,可以组合使用(DAC+caps)或单独使用(LSM、命名空间)。您还可以将它们组合起来以提供深度防御。但是,问题限制一切是否有益与您如何调解特权和表示完全特权的概念(CAP_SYS_ADMIN、UID 0、未命名空间的特权用户、LSM 的特定概念)非常无关。
当您编写操作系统并希望它能够适应用户的需求时,您需要提供更新和重新配置它以及运行新服务的方法。如果系统维护涉及更新安全服务、访问控制策略、内核和硬件模块等操作,那么您必须提供一种方式让人类用户充当完全特权的参与者,或者您必须拥有第三方-party 系统,可以调整您的操作系统并将调整后的版本部署在您的用户数据之上。在高安全性上下文中,后者可能是可取的(坦率地说,这在概念上就像运行 VM 一样简单)。然而,在由一群自行维护其系统的用户进行通用计算的情况下,您无法摆脱完全特权身份。
init 进程必须首先以 root 身份运行。但从根本上说,root 的定义并不是 id 为 0 的用户,而是具有访问内核例程能力的进程所有者。您可以强制执行一个系统,其中对于 AAA,您只运行与提交的作业相关的命令,但除此之外没有理由删除 root 用户。另一件事是:使系统诱人的不是根帐户,而是机器上运行的服务具有数据或能够传输数据的事实才是重点。
事实上,所有的“用户”都可以被删除......只有一个静态链接二进制程序的内核在没有任何 /etc/passwd 文件的情况下执行一项任务就可以很好地工作。当然,uids 和 euids 的概念仍然存在。
如果您的系统执行一项特定任务......只需将其全部删除。文件系统,引导加载程序,库,其余无用的废话。并直接在内核中运行您的任务。(从 rom 启动又是另一回事了;)当然,如果您的代码中存在远程漏洞,他们仍然可以获得访问权限,但没有 shell,因此它们仅限于远程任何代码(他们可以插入)。
- 据说 - 在 - 大多数正常系统上 - - 大多数黑客 - 对 uid0 的攻击不是通过暴力破解密码或拦截流量......而是通过使用围绕它构建的所有垃圾来 - 防止 -。特别是 sudo、traceroute 等。从用户 'www' 到 'root' 的大多数漏洞利用 - 需要一个 suid 二进制文件......并猜猜 su 和 sudo 是什么。
一旦系统完成......实际上没有明显的理由保留所有“访问”的东西,毕竟,如果有理由修复问题,可以将整个图像从开发平台更新到闪存中的部署基础设施或eeprom 存储而不是“访问它”以在本地或其他任何地方运行您的编辑器/编译器。