Gcc的-fstack-protector提供了一个随机的堆栈金丝雀，可以防止堆栈溢出，并通过控制返回地址目的地减少任意代码执行的机会。在编译时启用。(少数应用程序不能很好地使用它，并将其禁用。)用于堆栈检查的例程实际上是glibc的一部分，但是gcc打了补丁，默认情况下启用了针对这些例程的链接。

看到test-gcc-security.py用于回归测试。

堆保护器

GNU C库堆保护器(自动通过ptmalloc而且手册)为glibc堆内存管理器提供了损坏列表/断开链接/双自由/溢出保护(在glibc 2.3.4中首次引入)。这阻止了通过堆内存溢出执行任意代码的能力，这些溢出试图破坏malloc堆内存区域的控制结构。

随着时间的推移，这种保护不断发展，增加了越来越多的额外保护研究了一些极端案例．就目前的情况来看，glibc 2.10和后续版本似乎成功地抵抗了这些难以触及的条件。

看到test-glibc-security.py用于回归测试。

指针困惑

一些存储在glibc中的指针是模糊的在glibc内部通过PTR_MANGLE/PTR_UNMANGLE宏，防止libc函数指针在运行时被覆盖。

看到test-glibc-security.py用于回归测试。

地址空间随机布局(ASLR)

ASLR是由内核和ELF加载器通过随机分配内存位置(堆栈、堆、共享库等)来实现的。这使得当攻击者试图破坏内存时，内存地址难以预测。的值在系统范围内控制ASLR/proc/sys/kernel/randomize_va_space．在Ubuntu 8.10之前，默认为“1”(开启)。在后来包含brk ASLR的版本中，它默认为“2”(打开，使用brk ASLR)。

看到test-kernel-security.py查阅所有不同类型的ASLR的回归测试。

堆栈本

程序的每次执行都会导致不同的堆栈内存空间布局。这使得在内存中定位攻击或交付可执行攻击有效负载变得更加困难。这是自2.6.15 (Ubuntu 6.06)以来在主线内核中可用的。

Libs / mmap本

程序的每次执行都会导致不同的mmap内存空间布局(这导致动态加载的库每次都加载到不同的位置)。这使得在内存中很难找到跳转到“返回libc”以进行类似攻击的位置。这是自2.6.15 (Ubuntu 6.06)以来在主线内核中可用的。

执行本

使用"-fPIE -pie"构建的程序的每次执行都将被加载到不同的内存位置。这使得在执行基于内存损坏的攻击时，很难在内存中定位攻击或跳转到哪里。这是自2.6.25以来在主线内核中可用的(并且被反向移植到Ubuntu 8.04 LTS)。

brk本

类似于exec ASLR, brk ASLR调整exec内存区域和brk内存区域之间的内存位置(用于小malloc)。在2.6.26 (Ubuntu 8.10)中添加了来自exec内存的brk offset的随机化，尽管在Ubuntu 8.04 LTS中可以在PIE程序中看到一些brk ASLR的影响，因为exec是ASLR，并且brk是在exec区域之后立即分配的(所以它在技术上是随机的，但直到8.10之前对于文本区域并没有随机化)。

VDSO本

程序的每次执行都会产生一个随机的vdso位置。虽然自2.6.18 (x86, PPC)和2.6.22 (x86_64)以来，它就存在于主流内核中，但由于在Ubuntu 6.10中启用了COMPAT_VDSO，它在Ubuntu 8.04 LTS中被删除了。这可以防止跳转到系统调用攻击。glibc 2.6只支持x86(可能是ppc?)glibc 2.7 (Ubuntu 8.04 LTS)支持x86_64 ASLR vdso。需要古老的libc6前静态高vdso映射的人可以在内核引导命令行上使用“vdso=2”来再次获得COMPAT_VDSO。

• https://lwn.net/Articles/184734/

• https://articles.manugarg.com/systemcallinlinux2_6.html

以PIE形式建造

所有使用“-fPIE -pie”构建为位置独立可执行文件(PIE)的程序都可以利用exec ASLR。这可以防止“返回到文本”，并且通常可以挫败内存破坏攻击。这需要在构建整个存档时集中更改编译器选项。在具有少量通用寄存器的架构(例如x86)上，PIE有很大的性能损失(5-10%)，因此它最初只用于选择安全关键包个数(一些上游本地支持使用PIE构建，其他要求使用“硬化包装器”强制正确的编译器和链接器标志)。64位架构上的PIE没有相同的惩罚，它被设置为默认值(在16.10中，它是amd64、ppc64el和s390x上的默认值)。在17.10版本中，我们认为安全优势非常显著，默认情况下，Ubuntu存档中的所有架构都启用了PIE。

看到test-built-binaries.py用于回归测试。

内置与加强源

使用"-D_FORTIFY_SOURCE=2"(和-O1或更高)构建的程序，在glibc中启用了几个编译时和运行时保护:

• 当目标缓冲区的大小已知时，将对“sprintf”、“strcpy”的无限调用扩展为它们的“n”个长度有限的表亲(防止内存溢出)。
• 当格式字符串位于可写内存段中时，停止格式字符串“%n”攻击。
• 需要检查各种重要的函数返回码和参数(例如system, write, open)。
• 创建新文件时需要显式的文件掩码。

看到test-gcc-security.py用于回归测试。

由RELRO建造

针对加载器内存区域覆盖强化ELF程序，通过让加载器将重定位表的任何区域标记为在加载时解析的任何符号的只读(“只读重定位”)。这减少了可能发生get - override风格的内存损坏攻击的范围。

看到test-gcc-security.py用于回归测试。

用BIND_NOW构建

标记ELF程序在启动时解析所有动态符号(而不是按需，也称为“立即绑定”)，以便get可以完全只读(当与上面的RELRO结合时)。

看到test-built-binaries.py用于回归测试。

使用-fstack- collision -protection构建

在可变长度堆栈内存分配(通过alloca()或gcc可变长度数组等)周围添加额外的指令，以便在分配时探测每一页内存。这可以通过确保所有堆栈内存分配都是有效的来减轻堆栈冲突攻击(或者如果不是有效则引发分段错误，并将可能的代码执行攻击转换为拒绝服务)。

看到test-built-binaries.py用于回归测试。

使用-fcf-protection构建

指示编译器生成支持Intel控制流强制技术(CET)的指令。

看到test-built-binaries.py用于回归测试。

不可执行的内存

大多数现代cpu都防止执行不可执行的内存区域(堆、堆栈等)。这被称为Non-eXecute (NX)或eXecute-Disable (XD)，一些BIOS制造商在默认情况下不必要地禁用它，因此请检查您的BIOS设置．这种保护减少了攻击者可以用来执行任意代码执行的区域。它要求内核使用“PAE”寻址(也允许3GB以上的物理地址寻址)。64位和32位-服务器而且-generic-pae内核是用PAE寻址编译的。从Ubuntu 9.10开始，当处理器运行在32位内核(包含或不包含PAE)上时，部分模拟了缺少NX的这种保护。启动后，你可以看到NX保护的效果:

• 基于硬件(通过PAE模式):

  [0.000000] NX(执行禁用)保护:激活

• 部分仿真(通过段限制):

  [0.000000]使用x86段限制近似NX保护

如果两者都没有显示，则没有启用任何NX保护。检查BIOS设置和CPU能力。如果“nx”出现在每一行的“flags”中/proc/cpuinfo，它是由您的硬件启用/支持的(实际使用它需要一个PAE内核)。

从Ubuntu 11.04开始，BIOS NX设置为被内核忽略．

看到test-kernel-security.py用于回归测试。

/proc/$ pid /地图保护

使用ASLR，进程的内存空间布局突然变得对攻击者有价值。“maps”文件是由只读除了进程本身或进程的所有者。在2.6.22中使用sysctl切换进入主线内核。在2.6.27中，这个切换变成了非可选的，强制启用隐私，无论sysctl设置如何(这是一件好事)。

看到test-kernel-security.py用于回归测试。

符号链接的限制

一类长期存在的安全问题是基于符号链接的ToCToURace，最常见于世界可写目录，如/ tmp /．的常用开发方法这一缺陷当跟随给定的符号链接(即根用户跟随属于另一个用户的符号链接)。

在Ubuntu 10.10及以后版本中，符号链接在全球可写的sticky目录中(例如。/ tmp)如果追随者和目录所有者不匹配符号链接所有者，则不能跟随。控件控制该行为/proc/sys/kernel/yama/protected_sticky_symlinksSysctl，可通过阎罗王．

看到test-kernel-security.py用于回归测试。

Hardlink限制

硬链接可以被滥用类似的方式到上面的符号链接，但它们不限于全球可写目录。如果/ etc /而且/home/都是在同一个分区上，普通用户可以创建硬链接到/etc/shadow在他们的主目录中。虽然它保留了原始的所有者和权限，但是符号链接安全的特权程序可能会通过硬链接错误地访问该文件。此外，攻击者可能会通过用硬链接填充一个全局可写目录来耗尽磁盘空间，从而导致一个非常小的不可追踪的配额绕过本地拒绝服务。

在Ubuntu 10.10及更高版本中，硬链接无法创建到用户原本无法读写的文件，或者是其他敏感文件。控件控制该行为/proc/sys/kernel/yama/protected_nonaccess_hardlinksSysctl，可通过阎罗王．

看到test-kernel-security.py用于回归测试。

FIFO的限制

进程可能不会检查正在创建的文件是否实际创建为所需的类型。这种全局控制禁止某些可能不安全的配置工作。

看到内核admin-guide为文档。

常规文件限制

进程可能不会检查正在创建的文件是否实际按照需要创建。这种全局控制禁止某些可能不安全的配置工作。

看到内核admin-guide为文档。

ptrace范围

Linux进程的一个令人不安的弱点接口是指单个用户能够检查内存和它们的任何进程的运行状态。例如，如果一个应用程序被破坏了，攻击者有可能附加到其他正在运行的进程(例如SSH会话，GPG代理，等)提取额外的凭证，并继续立即扩大范围他们的攻击没有诉诸于用户辅助的网络钓鱼或木马。

在Ubuntu 10.10及更高版本中，用户不能跟踪非调试器后代的进程。控件控制该行为/proc/sys/kernel/yama/ptrace_scopeSysctl，可通过阎罗王．

在自动崩溃处理程序的情况下，崩溃进程可以特定地允许现有的崩溃处理程序进程在逐进程使用的基础上附加prctl(PR_SET_PTRACER, debugger_pid, 0,0,0)．

看到test-kernel-security.py用于回归测试。

内核硬化

内核本身启用了保护，使其更难以受到威胁。

0-address保护

由于内核和用户空间共享虚拟内存地址，因此需要保护“NULL”内存空间，以便用户空间mmap的内存不能从地址0开始，从而阻止“NULL解引用”内核攻击。这在2.6.22内核中是可能的，并且是通过sysctl设置“mmap_min_addr”实现的。从Ubuntu 9.04开始，mmap_min_addr设置被内置到内核中。(x86为64k, ARM为32k。)

看到test-kernel-security.py用于回归测试。

/dev/mem保护

一些应用程序(Xorg)需要从用户空间直接访问物理内存。特殊文件/dev/mem存在是为了提供这种访问。在过去，如果攻击者具有根访问权限，则可以从该文件查看和更改内核内存。的CONFIG_STRICT_DEVMEM内核选项引入来阻止非设备内存访问(最初命名为CONFIG_NONPROMISC_DEVMEM)。

看到test-kernel-security.py用于回归测试。

/dev/kmem禁用

没有现代的使用者/dev/kmem除了攻击者使用它来加载内核rootkit之外。CONFIG_DEVKMEM设置为“n”。而/dev/kmem设备节点仍然存在于Ubuntu 8.04 LTS到Ubuntu 9.04，它实际上没有附加到内核中的任何东西。

看到test-kernel-security.py用于回归测试。

块模块加载

在Ubuntu 8.04 LTS和更早的版本中，这是可能的从系统范围的能力边界集中移除CAP_SYS_MODULES，这将阻止任何新的内核模块被加载。这是阻止内核rootkit被安装的另一层保护。2.6.25 Linux内核(Ubuntu 8.10)改变了边界集的工作方式，这个功能消失了。从Ubuntu 9.10开始，现在是可以阻塞模块加载同样是通过设置“1”/proc/sys/kernel/modules_disabled．

看到test-kernel-security.py用于回归测试。

只读数据段

这确保某些内核数据节被标记为阻止修改。这有助于防止某些类型的内核rootkit。通过CONFIG_DEBUG_RODATA选项启用。

看到test-kernel-security.py用于配置回归测试。

堆栈保护

与用户空间中ELF程序使用的堆栈保护器类似，内核也可以保护其内部堆栈。通过CONFIG_CC_STACKPROTECTOR选项启用。

看到test-kernel-security.py用于配置回归测试。

模块RO / NX

这个特性扩展了CONFIG_DEBUG_RODATA，为内核中加载的模块包含了类似的限制。这可以帮助抵抗未来依赖于加载模块中不同内存区域的内核攻击。通过CONFIG_DEBUG_MODULE_RONX选项启用。

看到test-kernel-security.py用于配置回归测试。

内核地址显示限制

当攻击者试图针对内核漏洞开发“随处运行”的漏洞时，他们通常需要知道内核内部结构的位置。通过将内核地址视为敏感信息，这些位置对普通本地用户是不可见的。从Ubuntu 11.04开始，/proc/sys/kernel/kptr_restrict设置为“1”以阻止报告已知的内核地址泄漏。此外，各种文件和目录只能由根用户读取:/ boot / vmlinuz *，/ boot / System.map *，/ sys /内核/调试/，/proc/slabinfo

看到test-kernel-security.py用于回归测试。

内核地址空间布局随机化

内核地址空间布局随机化(kASLR)旨在通过随机化内核的基址值，使某些内核攻击更难实现。依赖内部内核符号位置的攻击必须发现随机基址。

kASLR从Ubuntu 14.10开始可用，在16.10及更高版本中默认启用。

在16.10之前，您可以在内核命令行上指定“kaslr”选项来使用kaslr。

通常，内核允许所有网络协议根据需要通过MODULE_ALIAS_NETPROTO (PF_…)宏。由于这些协议中的许多都是老旧的、罕见的，或者对普通Ubuntu用户来说没什么用，并且可能包含未被发现的可利用漏洞，因此从Ubuntu 11.04开始，它们就被拒绝了。其中包括:ax25、netrom、x25、rose、decnet、econet、rds和af_802154。如果需要任何协议，可以通过modprobe或/etc/modprobe.d/blacklist-rare-network.conf文件可以更新以删除拒绝列表条目。

看到test-kernel-security.py用于回归测试。

系统调用过滤

方法可以过滤掉内核系统调用的可用性seccomp_filter接口．这是在容器或沙箱中完成的，当可能运行不受信任的软件时，这些容器或沙箱希望进一步限制对内核接口的暴露。

看到test-kernel-security.py用于回归测试。

dmesg命令限制

当攻击者试图为漏洞开发“随处运行”的漏洞时，他们通常会使用dmesg输出。通过将dmesg输出视为敏感信息，攻击者无法获得此输出。从Ubuntu 12.04 LTS开始，/proc/sys/kernel/dmesg_restrict可以设置为“1”以将dmesg输出视为敏感。从20.10开始，默认情况下启用此功能。

块kexec

从Ubuntu 14.04 LTS开始，现在是可以禁用kexec通过sysctl。CONFIG_KEXEC已在Ubuntu中启用，因此最终用户可以根据需要使用kexec，新的sysctl允许管理员禁用kexec_load。例如，在设置了CONFIG_STRICT_DEVMEM和modules_disabled的环境中需要这样做。

UEFI安全引导(amd64)

从Ubuntu 12.04 LTS开始，UEFI安全引导以引导加载程序的强制模式和内核的非强制模式实现。使用此配置，验证失败的内核将在未启用UEFI怪癖的情况下启动。Ubuntu 18.04 LTS的Ubuntu 18.04.2版本为引导加载程序和内核启用了强制模式，因此验证失败的内核将不会被引导，验证失败的内核模块将不会被加载。计划将其反向移植到Ubuntu 16.04 LTS和Ubuntu 14.04 LTS上(但是仅对Ubuntu 14.04 LTS进行内核签名强制，而不是内核模块签名强制)。

usbguard

从Ubuntu 16.10开始，usbguard包已经在universe中提供了一个工具，用于使用Linux内核的USB授权支持，来控制将被识别的设备id和设备类。

usbauth

从Ubuntu 18.04开始，usbauth包已经在universe中提供了一个工具，用于使用Linux内核的USB授权支持，来控制将被识别的设备id和设备类。

螺栓

从Ubuntu 18.04开始，bolt包已经在main中提供了一个面向桌面的工具，用于使用Linux内核的Thunderbolt授权支持。

thunderbolt-tools

从Ubuntu 18.04开始，Thunderbolt -tools包已经在universe中提供了一个面向服务器的工具，用于使用Linux内核的Thunderbolt授权支持。

内核封锁

从Ubuntu 20.04开始，Linux内核的锁定模式在完整性模式下启用。这可以防止根帐户加载可以操作内核数据结构的任意模块或BPF程序。锁定强制与UEFI安全引导绑定。

附加的文档

• 与Debian的配合:https://wiki.debian.org/Hardening

• Gentoo的硬化项目:https://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml

• Ubuntu所有版本的安全特性

如果您对这些功能有疑问或意见，请联系保安团队．

CategorySecurityTeam