Gentoo Hardened 对比其他发行版

信息安全 硬化 海合会
2021-08-18 00:02:27

我想知道 Gentoo 的强化配置文件是否真的比任何其他发行版(如 Debian、RHEL、Arch ...)更安全。对于那些不知道的人,Gentoo 强化允许使用特定的强化 GCC 选项(pie、ssp、relro、...)和其他一些东西(grsec/selinux...)在系统范围内构建系统。

例如,我知道 Arch Linux 不会使用那些 GCC 强化标志构建所有二进制文件,那么这是否意味着对安全性的某种关注?

我知道 OpenVPN 是在没有 PIE 和部分 relro 的情况下构建的。这是否意味着如果发现针对 OpenVPN 的漏洞利用,Arch 安装可能不如 Gentoo 安全?

TL;DR:就二进制文件的安全性而言,使用 Gentoo Hardened 是否比任何其他发行版真正具有优势?

1个回答

一切尽在源头!Gentoo hardened 是一个安全驱动的发行版,经过强化的配置文件确实包含了很多内容以使其真正安全。

但值得编译吗?linux论坛中的一个大问题。

让我们看看 Gentoo 强化的安全配置文件:

虽然它增加了一些安全性,但它是如此之少,以至于在大多数情况下它不值得。它在二进制发行版上提供了更高的安全性,因为每个人都拥有相同的二进制文件,攻击者不需要猜测特定代码段可能会加载到哪里,但是通过运行源发行版,您的地址空间已经非常独特。它提供一些安全性的唯一情况是,当攻击者试图猜测一个漏洞的地址时,错误的猜测可能会导致进程崩溃,并将重新加载到新地址。您是否有足够有价值的数据让攻击者通过这些麻烦来获取它?如果你这样做了,那么你应该使用强化配置文件,但是物理安全和磁盘加密更重要,因为如果它值那么多钱,那么抢劫你会更容易。

请注意,没有强化的桌面配置文件,因此如果计划在桌面上使用它,仅此一项就会变得更加困难。

另一个原因是,如果您想使用像 SELinux(不需要强化配置文件)这样的东西,它可以为您提供非常精细的访问控制控制,但它也非常严格。我认为只有拥有许多用户和不同级别的敏感数据访问权限的大型网络才值得这样做。

我需要一些 SELinux 功能,但决定以一种不寻常的方式使用 AppArmor 来完成它们,因为 SELinux 太麻烦了。AppArmor 所做的只是提供进程隔离或沙盒。如果攻击者通过exploint获得访问权限,他将只能访问被利用服务有权访问的文件。我将它与一个 catch all 配置文件一起使用,该配置文件可以防止从所有世界可写目录和主目录执行,以及访问 ssh/pgp 密钥、密钥环等。这对服务器和台式机来说很好用,而且限制不是很大。如果我需要从我的主目录执行代码进行开发,我可以通过 sudo 启动一个不受限制的 shell。

但是是什么让它变硬了呢?让我们看看其中一些项目:

  • PaX 是一个内核补丁,可以保护我们免受堆栈和堆溢出的影响。PaX 通过使用 ASLR(地址空间布局随机化)来做到这一点,它使用内存中的随机内存位置。每个 shellcode 都必须使用一个地址跳转到嵌入其中以获得代码执行,并且由于内存中缓冲区的地址是随机的,这要实现起来要困难得多。PaX 通过将程序使用的数据保存在不可执行的内存区域中增加了额外的保护层,这意味着攻击者将无法执行它设法写入内存的代码。为了使用 PaX,我们必须使用支持 PaX 的内核,例如 hardened-sources。
  • PIE/PIC(与位置无关的代码):通常,可执行文件有一个固定的基地址,它们被加载的地方。这也是添加到 RVA 的地址,以便计算可执行文件中函数的地址。如果可执行文件是在支持 PIE 的情况下编译的,则它可以加载到内存中的任何位置,而如果在不支持 PIE 的情况下编译,则必须将其加载到固定地址。如果我们想使用 PaX 来利用 ASLR,则需要启用 PIE。
  • RELRO(重定位只读):当我们运行可执行文件时,加载的程序需要写入一些在应用程序启动后不需要标记为可写的部分。这些部分是 .ctors、.dtors、.jcr、.dynamic 和 .got [4]。如果我们将这些部分标记为只读,则攻击者将无法使用在尝试获取代码执行时可能使用的某些攻击,例如覆盖 GOT 表中的条目。
  • SSP(堆栈粉碎保护器)用于用户模式;它通过在堆栈上放置金丝雀来防止堆栈溢出。当攻击者想要溢出堆栈上的返回 EIP 地址时,他还必须溢出随机选择的金丝雀。当这种情况发生时,系统可以检测到金丝雀已被覆盖,在这种情况下应用程序被终止,因此不允许攻击者跳转到内存中的任意位置并从那里执行代码。
  • RBAC(基于角色的访问控制):请注意,RBAC 与我们稍后会介绍的 RSBAC 不同。RBAC 是 SELinux、grsecurity 等可以使用的访问控制。默认情况下,文件的创建者对文件具有完全控制权,而 RBAC 则强制 root 用户控制文件,而不管是谁创建的它。因此,系统上的所有用户都必须遵守系统管理员设置的 RBAC 规则。

此外,我们还可以使用以下访问控制系统,用于控制进程和对象之间的访问。通常,我们必须选择下面概述的系统之一,因为一次只能使用一个访问控制系统。访问控制系统包括以下内容:

  • SELinux(安全增强型 Linux)
  • AppArmor(应用装甲)
  • Grsecurity,其中包含可应用于内核的各种补丁,以提高整个系统的安全性。如果我们想在内核中启用 grsecurity,我们必须使用启用 grsecurity 的内核,即 hardened-sources。
  • RSBAC(基于规则集的访问控制):我们必须使用 rsbac-sources 内核来构建支持 rsbac 的内核。

这一切都归结为前面所说的大问题?值得编译吗?真正归结为您要确保的方式或内容,付出的努力是否值得?或者你能真正保护你不想窥探的东西吗?