安全 - Arch Linux 中文维基

跳转到内容

# 安全

来自 Arch Linux 中文维基
翻译状态：

- 本文（或部分内容）译自 Security，最近一次同步于 2024-01-20，若英文版本有所更改，则您可以帮助同步与翻译更改的内容。
- 您可以在 ArchWiki 的对应页面找到本文翻译的原始修订历史。
- 本文可能与英文原文存在出入。

相关文章

- Arch 安全团队
- 建议阅读
- 认证管理
- Capabilities
- 应用程序列表/安全

本文包含了加固 Arch Linux 系统的常用建议与最佳实践。

## 概念

- 收紧安全措施有可能达到使系统无法使用的程度。安全性与便利性需要得到平衡。诀窍在于建立一个安全且有用的系统。
- 最大的威胁是（并且一直都会是）用户。
- 最小权限原则：系统的每一部分应该只能访问到它确实需要的东西，除此之外的则不可以。
- 纵深防御：多个独立的层次能带来更好的安全性。当一层防护被攻破时，另一层应该能够阻止攻击。
- 保持一点点的偏执和多疑。如果有件事看起来太好了，不像是真的，那可能确实如此。
- 永远无法令系统 100% 安全，除非把机器从网络上断开，关掉电源，锁进保险柜，用混凝土封住并不再使用它。
- 为失败做好准备。预先为安全措施被攻破的情况制定可供执行的计划。

## 密码

密码是一个安全系统的关键。它可以保护你的用户账户、加密的文件系统和 SSH/GPG 密钥。密码也是让计算机信任使用者的主要方式，所以安全性的很大一部分就在于选择高强度的密码并保护它们不被泄露。

### 选择安全的密码

密码必须足够复杂，不能轻易地被猜中（比如和个人信息有关的密码），也不能轻易地被社会工程或暴力尝试等方法破解。强密码的要点在于长度和随机性。在密码学中，密码的质量被称为它的熵安全性。

不安全的密码包括：

- 个人可识别信息（如：狗的名字，出生日期，区号，最喜欢的视频游戏）
- 对单词简单地替换一些字符（如：`k1araj0hns0n`），因为现代字典攻击可以轻松对付它们
- 在基本单词或常见字符串的前后加上数字，符号或其他字符（如：`DG091101%`）
- 常见句子或词典中单词的序列（如：`photocopyhauntbranchexpose`），包括对其字符进行替换（如：`Ph0toc0pyh4uN7br@nch3xp*se`）
- 任何一个最常见的密码

最好的选择是由随机来源生成的长密码（越长越好）。使用长密码很重要。弱哈希算法会使得一个8字符密码的哈希值在几小时之内便被攻破。

像 pwgen包 或 apgAUR 这样的工具可生成随机密码，不过这些密码可能很难记住：为了记住它们，一种方法（仅针对经常使用的密码）是生成一个长密码并记住一小段（这一小段要能保证最低限度的安全），暂时把完整的密码写下来。在一次次的密码输入过程中，尝试着记住从一小段到一大段乃至全部密码，随着时间推移，密码就会随着肌肉记忆根深蒂固。这种方法很难，但是能保证密码不会出现在破解用的字典里，也可以抵御“智能地”组合单词并替换部分字符的暴力破解手段。

除了密码管理，keepassxc包 还提供密码/口令生成功能。用户可以在图形用户界面中自定义生成密码。还支持基于字典的口令。

还有个方法可以产生安全性好的、看起来随机的密码，那就是从一句句子的每一个词中提炼出一个符号。 例如 “the girl is walking down the rainy street” 这句话可以转换为 `t6!WdtR5` 或是更加复杂的 `t&6!RrlW@dtR,57`。 这种方法可以更为简单地帮助记忆密码，但是请注意，不同字母出现在单词开头的概率不同 (Wikipedia:Letter frequency)。

另外一种有效的技术是写下随机生成的密码并将其存储在安全的地方，例如钱包、挎包或文件保险箱中。不少人在保护其物理贵重物品免受盗窃方面通常做得很好，并且与数字安全实践相比，大多数人更容易理解物理安全最佳实践。

将助记符和随机技术结合起来，通过密码管理器保存长的随机生成的密码也非常有效。密码管理器需要用一个易记的“主密码”来访问，这个密码只能用于此目的。主密码必须记住，绝不能保存。这就要求在系统上安装密码管理器，以便轻松访问密码（根据情况，这可以被视为不方便或安全特性）。一些密码管理器还有智能手机应用，可以用来显示用于在没有安装该密码管理器的系统上进行手动输入的密码（如果这是常见的使用情况，那么你仍然可以为每个服务使用易于输入但安全的密码，而不是完全随机的密码，参见下文）。注意，如果你忘记了主密码，密码管理器就引入了一个单点故障。

有些密码管理器根据主密码和你想要登录的服务名称计算包含的密码，而不是加密它们，使得在新的系统上无需同步任何数据也可以使用它。

使用一长串相互无关的单词作为密码或许是有效的方法。原理在于，如果使用足够长的短语，从密码长度所获得的熵就可以抵消使用字典词汇而失去的熵。这个 XKCD 漫画描绘了此方法中对于熵的权衡，考虑到短语中每个单词可能的单词集的限制。如果你使用的单词集很大（数千个单词）并且您从中选择 5-7 个甚至更多随机单词，那就算攻击者知道你所选择的可能单词集和选择的单词数量，这种方法仍能提供很大的熵。参见Diceware。

参阅 The passphrase FAQ 或 Wikipedia:Password strength ，获取额外背景信息。

### 维护密码安全

一旦你选择了一个强密码，就一定要保证它的安全。当心键盘记录器（软件层面 和 硬件层面），屏幕记录器，社会工程，肩窥，并避免对不同的服务器（网站）使用重复密码，以防止不安全的服务器泄漏超出其范围的信息。密码管理器可以帮助管理大量复杂密码：将密码从管理器复制粘贴到其他程序中时，记住每次粘贴完都清除复制缓冲区，并确保密码不会“意外地”保存在任何类型的文件中（例如，不要将它们粘贴在普通的终端命令中，因为这些命令会存到 `.bash_history` 之类的文件里）。

最好不要因为安全性强的密码难记而选择不安全的密码，密码是它们之间的一种平衡。与拥有许多相似的弱密码相比，更好的做法是建立一个加密的安全密码数据库，数据库由密钥和一个强主密码保护着。把密码写下来也许同样有效[1]，可以避开软件中的潜在漏洞，同时也需要保证物理安全。

衡量密码强度的另一个指标是它不能够被轻易从其他地方恢复。

如果你使用与登录密码相同的磁盘加密密码（这在登录时自动挂载加密分区或目录很有用），请确保 `/etc/shadow` 也在加密分区上，或者/并 使用强哈希算法（即 sha512/bcrypt，而不是 md5）来存储密码哈希（详细信息请参阅 SHA password hashes）。

如果要备份密码数据库，请勿将备份的副本存储在密码保护之下（比如存储在加密的驱动器或需要身份验证的远程存储服务），而解锁副本的密码又存储在副本中，这样在需要时将无法访问它（相当于把房间的钥匙锁在了房间里）。一个有用的技巧是，使用主密码的简单哈希来加密存储密码数据库的驱动器或帐户。维护一份记录备份位置的列表：如果有一天你觉得主密码已被泄露，一是要更改所有数据库备份的密码，二是要使用从新主密码派生的新哈希来保护存有数据库的位置。

以安全的方式控制数据库的版本可能非常复杂：如果你这样做，那你必须有办法更新所有数据库版本的主密码。主密码泄露时，你可能并不能马上知道：为了降低其他人在你意识到主密码泄露之前发现密码的风险，你可以选择定期更改主密码。如果你担心自己失去了对数据库副本的控制权，则需要根据主密码的熵，在暴力破解主密码所需的时间内更改数据库副本中包含的所有密码。

### 密码的散列值

这篇文章的某些内容需要扩充。

原因：提及密钥导出函数，特别是 PBKDF2、bcrypt 和 scrypt，应当提及用法、优缺点，基于定制硬件的暴力攻击应当特别提及。 (在 Talk:安全 中讨论)

默认情况下，Arch 将用户密码散列值存储在仅 root 可读的 `/etc/shadow` 文件中，与存储在所有人可读的 `/etc/passwd` 文件中的其他用户参数分开，请参阅 Users and groups#用户信息存储。另请参阅 #限制 root 权限。

密码使用 passwd 命令来设置，该命令使用 crypt 函数对密码进行拉伸，然后将它们保存在 `/etc/shadow` 中。请参阅 SHA password hashes。密码也被加盐（salted），以抵御彩虹表攻击。

另请参阅在 Linux 中密码如何存储（理解使用 shadow 工具的散列值化）。

### 用 pam_pwquality 强制使用强密码

pam_pwquality 提供针对字典攻击的保护，并可用于配置在整个系统中实施的密码策略。它基于 pam_cracklib，故也向后兼容其选项。

安装 libpwquality包 软件包。

警告：root 账户默认不会受此策略影响。
注意：可以用 root 帐户来帮助想绕过策略的用户设置他们的密码。这在设置临时密码时很有用。
注意：目前有关密码的安全指南（例如来自 NIST 以及其他机构的指南）并不建议强制使用特殊字符，因为它们通常只会导致可预测的更改。

举个例子，假设要强制执行下面的策略：

- 如果密码错误，则提示 2 次输入密码（retry 选项）
- 最小长度为10个字符（minlen 选项）
- 输入新密码时，新密码应至少有 6 个字符与旧密码不同（difok 选项）
- 至少 1 个数字（dcredit 选项）
- 至少 1 个大写字母（ucredit 选项）
- 至少 1 个小写字母（lcredit 选项）
- 至少 1 个除上述之外的其他字符（ocredit 选项）
- 不能包含单词 "myservice" 和 "mydomain"
- 为 root 应用此策略

编辑 `/etc/pam.d/passwd` 文件，把它改成：

    #%PAM-1.0
    password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
    password required pam_unix.so use_authtok sha512 shadow

`password required pam_unix.so use_authtok` 用来告诉 pam_unix 模块不要显示输入密码的提示符，而采用 pam_pwquality 所提供的。

更多信息可以参考 pam_pwquality(8) 和 pam_unix(8) 手册页。

## CPU

### 微码

关于如何为CPU微码安装重要安全更新的信息见微码。

### 硬件漏洞

有些 CPU 存在硬件漏洞。这些漏洞的列表见关于硬件漏洞的 Linux 内核文档，其中也包含了修补方法选择指南，有助于针对特定场景对内核自定义，从而修补这些漏洞。

要检查是否受到已知漏洞影响，请运行：

    $ grep -r . /sys/devices/system/cpu/vulnerabilities/

大部分情况下，更新内核和微码能够修补漏洞。

#### 同步多线程（超线程）

注意：这主要是使一些虚拟化程序受益的功能。在普通系统上启用它几乎没有或没有安全性益处。

同步多线程（SMT），在英特尔 CPU 上又称超线程，这一硬件功能可能是 L1 Terminal Fault 与微架构数据采样（Microarchitectural Data Sampling）漏洞的来源。 Linux 内核和微码更新含有针对已知漏洞的补丁，但是如果存在不受信任的虚拟化客户机，则对于某些 CPU 可能仍然需要禁用 SMT。

SMT 往往可以在系统固件中关闭。更多信息见主板或系统文档。通过添加以下内核参数，也可以在内核中禁用 SMT：

    mitigations=auto,nosmt

## 内存

#### 加固 malloc

hardened_malloc (hardened_mallocAUR, hardened-malloc-gitAUR) 是 glibc 函数 malloc() 加固过的替代品。此项目最开始由 GrapheneOS 的 Daniel Micay 开发，集成在 Android 的 Bionic 和 musl，他也内置了对 x86_64 标准 Linux 发行版的支持。

虽然 hardened_malloc 还没有被整合进 glibc（欢迎提供帮助或提交 pull request），但它可以通过 LD_PRELOAD 很容易地使用。在目前的测试中，如果在 /etc/ld.so.preload 中全局启用，它只会对少数应用程序造成问题。由于 hardened_malloc 会带来性能开销，你可能希望根据具体的攻击面和性能需求，针对性地决定使用哪种实现方式。

本文或本章节的事实准确性存在争议。

原因： Firefox 可能需要重新编译才能使用 hardened-malloc（在 [[2]] 中讨论）

如需单独使用，用 hardened-malloc-preload 包装脚本，或者手动启动应用程序并设置正确的预加载值。

    LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

在此页中可以找到如何正确地与 Firejail 配合使用，一些针对 hardened_malloc 的配置编译选项可以在 GitHub 仓库中找到。

## 存储

### 静态数据加密

静态数据加密，最好是使用强密码的全磁盘加密，是保护数据免受物理恢复的唯一方法。这在计算机关闭或相关磁盘卸载时提供了数据机密性。

然而，一旦计算机启动并且驱动器被挂载，其数据将变得与未加密的驱动器一样容易受到攻击。因此，最佳做法是在不再需要数据分区时立即卸载它们。

你还可以使用存储在 TPM 中的密钥对驱动器进行加密，尽管它过去存在可以通过总线嗅探攻击提取密钥的漏洞。

某些程序，如 dm-crypt，允许用户将 Loop file 加密为虚拟卷。当系统只有特定的部分需要加密时，这种方法可以替代全盘加密。

虽然数据静态加密wiki 中比较的基于块设备或文件系统的加密类型对于保护物理媒体上的数据很有用，但大多数不能用于保护无法控制的远程系统上的数据（例如云存储）。在某些情况下，个别文件加密会很有用。

以下是一些加密文件的方法：

- 一些归档和压缩工具还提供基本的加密功能。一些示例是 p7zip（ `-p` 标志）、zip包（ `-e` 标志）。加密时要特别小心，因为这些工具可能使用自定义算法来实现跨平台兼容性[1]。
- GnuPG 可用来加密文件。
- age包 是一款简单易用的文件加密工具。它还支持多个收件人和使用 SSH 密钥进行加密，这对于安全文件共享非常有用。

### 文件系统

如果用 sysctl 启用了内核的 `fs.protected_hardlinks` 和 `fs.protected_symlinks` 选项，内核就可以防止出现硬链接和软链接（符号链接）相关的安全问题。因此将全局可写的目录独立出来不再具有安全方面的优势。

使包含全局可写目录的文件系统保持独立 仍然可以作为一种防止恶意程序填充垃圾内容使磁盘空间耗尽的粗略手段。但是，把 `/var` 或 `/tmp` 所在分区塞满也足以使系统停止响应。处理这种问题的更灵活的机制是存在的（比如磁盘配额），并且某些文件系统自身就带有相关功能（Btrfs 的子卷可以设置配额）。

#### 挂载点

根据最小权限原则，挂载文件系统时应该采用最为严格的挂载选项（在不损失功能的情况下）。

相关的挂载选项有：

- `nodev`: 文件系统中，禁止解释任何字符或屏蔽特殊设备。
- `nosuid`: 禁止 set-user-identifier 或 set-group-identifier 标志位生效。
- `noexec`: 禁止文件系统里的任何二进制文件直接运行。
  - 在 `/home` 上设置 `noexec` 选项会禁用可执行脚本，影响 Wine* 、PyCharm 、 Steam 、 .NET等软件正常运行。
    - Wine 不需要 `exec` 标志来打开 Windows 二进制文件。仅当 Wine 本身安装在 `/home` 中时才需要它。
    - 为了保持 Steam 正常工作，你可以通过在 fstab 中添加以下内容来让 `/home/user/.local/share/Steam` 以 `exec`标志挂载 ：

          /home/user/.local/share/Steam  /home/user/.local/share/Steam  none defaults,bind,user,exec,nofail  0  0

  - 部分软件包（比如编译 nvidia-dkms包）可能需要 `/var` 目录下有 `exec` 权限。

用于存放数据的文件系统应该坚持使用 `nodev`、`nosuid` 和 `noexec` 挂载。

可能的文件系统划分参考：

- `/var`
- `/home`
- `/dev/shm`
- `/tmp`
- `/boot`

提示：使用 GPT 分区自动挂载 时，ESP 和 XBOOTLDR 分区始终使用`noexec,nosuid,nodev`挂载选项。

### 文件访问权限

本文或本章节的事实准确性存在争议。

原因： chmod go-r does not "take away all permissions", it only removes the read permission.（在 [[3]] 中讨论）

默认的文件权限对几乎所有文件都赋予了读权限，修改文件权限可以在取得了非 root 账户（如`http` 或 `nobody` 账户）的攻击者面前隐藏有价值的信息。

您可以使用 chmod 取消组和其他人的所有权限：

例如：

    # chmod go-r path_to_hide

警告：不要广泛应用这个原则。请一次尝试一种配置，确保它值得隐藏，并且不会破坏程序功能。如果依赖于组，您可能需要从命令中删除`g`（或者如果已经运行，则使用`chmod g+r path`重新添加权限）。

需要考虑的一些路径是：

- `/boot` ：启动目录，其中包括 vmlinuz 和 initramfs 映像。
- `/etc/nftables.conf` ：nftables 配置，适用于 nftables包 和 iptables-nft包。
- `/etc/iptables`: 旧版 iptables 配置，适用于iptables包 。

可以修改默认的 Umask `0022` 来为新建的文件提高安全性。NSA RHEL5 安全指南建议将 umask 设置为 `0077` 以获得最充分的安全性，这将使得新文件无法被创建者之外的用户读取。要修改 umask，参见 Umask#Set the mask value。如果你使用 sudo，可以考虑将其配置为使用默认的 root umask。

#### SUID and SGID files

It is important to be aware of any files with the Setuid or Setgid bit. Examples of relevant files in `/usr/bin` with the SUID bit set and owned by root:

- gpasswd
- pkexec
- Sudo
- su
- Passwd
- firejail

The prominent risks of such executable files include privilege escalation vulnerabilities, see e.g Wikipedia:Setuid#Security impact.[4][5][6]

Files with the SUID bit set and not owned by root, or files with the SGID bit set typically have less potential impact but can theoretically still do decent damage if vulnerable. It is usually possible to avoid using Setuid or Setgid by assigning Capabilities instead.

提示：It is vital to be vigilant in keeping packages which provide SUID/SGID executables up to date in order to prevent having a vulnerable system.

To search `/usr/bin` for files with either the SUID or SGID bit:

    $ find /usr/bin -perm "/u=s,g=s"

### 备份

本文或本章节可能需要合并到系统备份。

附注： 有专门的系统备份页面。（在 Talk:安全 中讨论）

定期创建重要数据的备份。定期测试备份的完整性。定期测试备份是否可以恢复。

确保至少一份数据副本离线存储，即不以任何方式连接到存在威胁的系统。勒索软件和其他破坏性攻击也可能攻击任何连接的备份系统。

参见系统备份。

### SATA SSD 冻结模式

参见固态硬盘#从睡眠中唤醒时设置SSD为"frozen"状态。

## 账户设置

### 不要日常使用 root 账户

根据最小权限原则，不要日常使用 root 账户。给每个使用系统的人建立一个没有特权的用户账户。必要时使用 Sudo 临时以高权限访问。

### 在失败的登录尝试后强制延时一段时间

将下方的行添加至 `/etc/pam.d/system-login` 即可在失败的登录尝试后延时至少 4 秒：

    /etc/pam.d/system-login

    auth optional pam_faildelay.so delay=4000000

`4000000` 是延时的微秒数。

### 在三次登录尝试失败后封锁用户

至 pambase包 20200721.1-2时，`pam_faillock.so` 默认启用，在15分钟内3次失败的登录尝试之后会封锁用户10分钟（见 FS#67644）。这一封锁只适用于密码认证（如登录及 sudo），通过 SSH 的公钥认证仍然会被接受。为防止彻底拒绝服务，该封锁对于 root 禁用。

要解锁用户，执行：

    $ faillock --reset --user username

默认情况下，封锁机制为每个用户一个文件，位于 `/run/faillock/`。删除或清空此文件及可解锁该用户——该目录是由 root 所有，但文件是由该用户所有，故 `faillock` 命令只会清空文件，因此并不需要 root。

`pam_faillock.so` 模块可通过文件 `/etc/security/faillock.conf` 配置。封锁参数：

- `unlock_time`——封锁时间（单位为秒，默认10分钟）。
- `fail_interval`——导致封锁的失败尝试时间范围（单位为秒，默认15分钟）。
- `deny`——封锁前允许的登录失败次数（默认为3）。

提示：锁定的主要目的是减缓暴力攻击，使其变得不可行。因此，如果由于密码输入错误而导致的锁定变得过于频繁，请优先考虑放宽尝试次数，而不是减少锁定时间。
注意：`deny = 0` 会禁用封锁。

默认情况下，重新启动后所有用户锁都会丢失。如果攻击者可以重新启动计算机，则锁定持续存在会更安全。要使锁定持续存在，请将 `/etc/security/faillock.conf` 中的 `dir` 参数更改为 `/var/lib/faillock` 。

更改无需重启即可生效。更多配置选项见 faillock.conf(5) ，如启用 root 账户封锁、在中心化登录（如 LDAP）情况下禁用等。

### 限制进程数量

在有很多用户或存在不可信用户的系统上，限制每个用户同时可运行的进程数很重要，这样可以防止 fork bombs 以及其他拒绝服务攻击。`/etc/security/limits.conf` 决定了每个用户或组可以运行的进程数，默认情况下为空（除了有用的注释）。将以下行添加到此文件将限制所有用户每位最多运行 100 个活动进程，除非他们使用 `prlimit` 命令将此次会话的最大值显式地提高到 200。可以根据用户应当运行的进程数量或当前管理的系统的硬件条件来确定这些值。

    * soft nproc 100
    * hard nproc 200

当前每个用户运行的进程数量可以使用 `ps --no-headers -Leo user | sort | uniq -c` 查看。这可以帮助确定合适的进程限额。

### 使用 Wayland

尽量使用 Wayland 代替 Xorg。Xorg 的设计早于现代安全实践，并且被许多人认为是不安全的。例如，Xorg 应用程序可以在不活动时记录击键。

如果必须运行 Xorg，建议避免以 root 身份运行，参考Xorg#没有 root 权限的 Xorg。 在 Wayland 中，Xwayland 兼容层将自动使用无root权限的 Xorg。

## 限制 root 权限

按照系统的设计，root 用户是系统中最强大的用户。审计 root 用户帐户也很困难。因此，重要的是尽可能多地限制root用户帐户的使用。有多种方法可以保持 root 用户的权力，同时限制其造成损害的能力。

### 用 sudo 替代 su

本文或本章节可能需要合并到sudo。

附注： 这是一篇专门说明 sudo 的文章。（在 Talk:安全 中讨论）

出于多种原因，使用 sudo 进行特权访问比 su 更好。

- sudo 记录了普通权限用户运行每个特权命令的日志。
- root 用户的密码不需要告知每个请求 root 权限的用户。
- `sudo` 可以防止用户意外地以 root 身份执行无需该权限的命令，因为 sudo 并没有为 root 创建完整的终端。这符合最小权限原则。
- 可以为单个用户启用单个程序的 root 权限，而不用为了运行一个程序启用该用户对 root 的完整访问权。例如，要授予用户 alice 对特定程序的访问权限：

    # visudo

    /etc/sudoers

    alice ALL = NOPASSWD: /path/to/program

另外，也可以为所有用户开放单个程序。例如允许以普通用户身份从服务器挂载 Samba 共享：

    %users ALL=/sbin/mount.cifs,/sbin/umount.cifs

这将允许 users 组中的所有用户从任何机器 (ALL) 运行此系统的 `/sbin/mount.cifs` 和 `/sbin/umount.cifs` 命令。

提示：

要 `visudo` 使用指定版本的 `nano` 而不是 `vi`，

    /etc/sudoers

    Defaults editor=/usr/bin/rnano

Export `# EDITOR=nano visudo` 被认为存在严重安全风险，因为任何程序都可以作为 `EDITOR`。

#### 使用 sudo 编辑文件

参见Sudo#编辑文件。另外，你也可以使用像`rvim`或`rnano`这样具有受限功能的编辑器，它们可以安全地作为root用户运行。

### 限制 root 登录

正确配置 sudo 后，完全的 root 权限就可以被严格限制或停用，且不会损失太多可用性。要禁用 root 而允许使用 sudo，可以运行 `passwd -l root`。

#### 仅允许特定用户

PAM 的 `pam_wheel.so` 模块可以做到仅允许 `wheel` 组中的用户使用 su包登录。参见Su#su 和 wheel 用户组。

#### 拒绝 SSH 登录

即使你不想禁止 root 用户在本地登录，也最好禁止 root 通过 SSH 登录。这样做的目的是在用户可以在远程完全破坏系统之前添加额外的一层安全保护。

#### 使用 access.conf 指定允许的登录组合

当用户尝试通过 PAM进行登录时,系统会检查 `/etc/security/access.conf` 文件，并从中查找第一个 与其登录属性匹配的组合。随后，系统将根据该匹配规则决定允许还是拒绝此次登录尝试。

    +:root:LOCAL
    -:root:ALL

我们可以为特定的组和用户设置规则。在下面的示例中，用户 `archie`、`wheel` 组和 `adm` 组的所有成员都被允许进行本地登录，而所有其他登录尝试均被拒绝：

    +:archie:LOCAL
    +:(wheel):LOCAL
    +:(adm):LOCAL
    -:ALL:ALL

更多信息请参阅 access.conf(5)

## 强制访问控制

Mandatory access control（MAC, 强制访问控制）是一种安全策略，它与 Arch 以及大部分 Linux 发行版默认使用的 Discretionary access control （DAC, 自主访问控制）有很大的不同。MAC 本质上是对照着一个安全规则集，检查程序的每一个可能对系统造成影响的操作。与 DAC 方式相比，用户不能修改 MAC 的规则集。使用几乎任何强制访问控制系统都将显著提高计算机的安全性，尽管它们的实现方式存在差异。

### 基于路径的MAC

基于路径的访问控制是一种简单的访问控制形式，它根据文件的路径提供相应的权限。这种方式有个缺点，就是当文件改变路径以后相应的权限并没有随着文件一起移动。从积极的方面来说，基于路径的 MAC 可以在更广泛的文件系统上实现，这与基于标签的另一种可选方案是不同的。

- AppArmor 是一个由 Canonical 维护的 MAC 实现，它被看做是 SELinux 的简化版替代方案。

- Tomoyo 是另一种提供访问控制的系统，简单而易用。它的使用方式和内部实现都被设计得足够简单，需要的依赖也很少。

### 基于标签的MAC

基于标签的访问控制意味着每份文件都带有扩展属性用于决定它的安全权限。虽然这类系统应该比基于路径的控制更灵活，但它只适用于支持这些扩展属性的文件系统。

- SELinux 是一个基于 NSA 的项目，用于提高 Linux 的安全性。它完整实现了 MAC，将系统用户与角色独立开来。它实现了一个非常强大的多级 MAC 策略，可以在系统扩大和改变得超出其原始配置时也能轻松控制系统。

### 访问控制表 (ACLs)

Access Control Lists（ACLs，访问控制表）是以某种方式将规则直接附加到文件系统的一种可选方法。ACLs 将程序的实际操作与允许的操作对照，来实现访问控制。

## 内核加固

### 内核自我保护 / 漏洞防护

linux-hardened包 相较于 linux包 使用了基本内核加固补丁集和更多安全相关的编译时配置选项。也可以使用自定义编译选项来把握安全性和性能之间的平衡，而不是使用强调安全性的默认选项。

However, it should be noted that several packages will not work when using this kernel. For example:

- skypeforlinux-stable-binAUR
- throttled包

如果你用了内核代码树以外的驱动，比如 NVIDIA，可能会需要切换到它的 DKMS 包。

#### 用户空间 ASLR 比较

linux-hardened包 包为用户空间进程提供了改进的 ASLR（Address Space Layout Randomization，地址空间布局随机化）实现。paxtest包 命令可用于获取所提供熵的估计值：

##### 64 位进程

    linux-hardened 5.4.21.a-1-hardened

    Anonymous mapping randomization test     : 32 quality bits (guessed)
    Heap randomization test (ET_EXEC)        : 40 quality bits (guessed)
    Heap randomization test (PIE)            : 40 quality bits (guessed)
    Main executable randomization (ET_EXEC)  : 32 quality bits (guessed)
    Main executable randomization (PIE)      : 32 quality bits (guessed)
    Shared library randomization test        : 32 quality bits (guessed)
    VDSO randomization test                  : 32 quality bits (guessed)
    Stack randomization test (SEGMEXEC)      : 40 quality bits (guessed)
    Stack randomization test (PAGEEXEC)      : 40 quality bits (guessed)
    Arg/env randomization test (SEGMEXEC)    : 44 quality bits (guessed)
    Arg/env randomization test (PAGEEXEC)    : 44 quality bits (guessed)
    Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
    Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
    Randomization under memory exhaustion @~0: 32 bits (guessed)
    Randomization under memory exhaustion @0 : 32 bits (guessed)

    linux 5.5.5-arch1-1

    Anonymous mapping randomization test     : 28 quality bits (guessed)
    Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
    Heap randomization test (PIE)            : 28 quality bits (guessed)
    Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
    Main executable randomization (PIE)      : 28 quality bits (guessed)
    Shared library randomization test        : 28 quality bits (guessed)
    VDSO randomization test                  : 20 quality bits (guessed)
    Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
    Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
    Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
    Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
    Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
    Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
    Randomization under memory exhaustion @~0: 29 bits (guessed)
    Randomization under memory exhaustion @0 : 29 bits (guessed)

    linux-lts 4.19.101-1-lts

    Anonymous mapping randomization test     : 28 quality bits (guessed)
    Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
    Heap randomization test (PIE)            : 28 quality bits (guessed)
    Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
    Main executable randomization (PIE)      : 28 quality bits (guessed)
    Shared library randomization test        : 28 quality bits (guessed)
    VDSO randomization test                  : 19 quality bits (guessed)
    Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
    Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
    Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
    Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
    Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
    Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
    Randomization under memory exhaustion @~0: 28 bits (guessed)
    Randomization under memory exhaustion @0 : 28 bits (guessed)

##### 32 位进程（运行在 x86_64 内核上）

    linux-hardened

    Anonymous mapping randomization test     : 16 quality bits (guessed)
    Heap randomization test (ET_EXEC)        : 22 quality bits (guessed)
    Heap randomization test (PIE)            : 27 quality bits (guessed)
    Main executable randomization (ET_EXEC)  : No randomization
    Main executable randomization (PIE)      : 18 quality bits (guessed)
    Shared library randomization test        : 16 quality bits (guessed)
    VDSO randomization test                  : 16 quality bits (guessed)
    Stack randomization test (SEGMEXEC)      : 24 quality bits (guessed)
    Stack randomization test (PAGEEXEC)      : 24 quality bits (guessed)
    Arg/env randomization test (SEGMEXEC)    : 28 quality bits (guessed)
    Arg/env randomization test (PAGEEXEC)    : 28 quality bits (guessed)
    Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
    Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
    Randomization under memory exhaustion @~0: 18 bits (guessed)
    Randomization under memory exhaustion @0 : 18 bits (guessed)

    linux

    Anonymous mapping randomization test     : 8 quality bits (guessed)
    Heap randomization test (ET_EXEC)        : 13 quality bits (guessed)
    Heap randomization test (PIE)            : 13 quality bits (guessed)
    Main executable randomization (ET_EXEC)  : No randomization
    Main executable randomization (PIE)      : 8 quality bits (guessed)
    Shared library randomization test        : 8 quality bits (guessed)
    VDSO randomization test                  : 8 quality bits (guessed)
    Stack randomization test (SEGMEXEC)      : 19 quality bits (guessed)
    Stack randomization test (PAGEEXEC)      : 19 quality bits (guessed)
    Arg/env randomization test (SEGMEXEC)    : 11 quality bits (guessed)
    Arg/env randomization test (PAGEEXEC)    : 11 quality bits (guessed)
    Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
    Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
    Randomization under memory exhaustion @~0: No randomization
    Randomization under memory exhaustion @0 : No randomization

### 限制访问 proc 文件系统中的内核指针

注意：linux-hardened包 默认设置是 `kptr_restrict=2` 而不是 `0`。

将 `kernel.kptr_restrict` 设置为 1 将针对没有 `CAP_SYSLOG` 的普通用户隐藏 `/proc/kallsyms` 中的内核符号地址，这使得利用内核漏洞动态解析地址/符号变得更加困难。这对预编译好的 Arch Linux 内核没有多大帮助，因为攻击者可以直接下载到内核包并从那里手动获取符号，但如果你正在编译自己的内核，这可以帮助减轻本地根攻击。这样做以后会影响非 root 用户运行部分 perf包 命令（虽然很多 perf包 功能本身就需要 root 权限）。更多信息请参见 FS#34323。

将 `kernel.kptr_restrict` 设置为 2 将隐藏 `/proc/kallsyms` 中的内核符号地址，而忽略用户的权限。

    /etc/sysctl.d/50-kptr-restrict.conf

    kernel.kptr_restrict = 1

### 禁用 BPF 即时编译

BPF is a system used to load and execute bytecode within the kernel dynamically during runtime. It is used in a number of Linux kernel subsystems such as networking (e.g. XDP, tc), tracing (e.g. kprobes, uprobes, tracepoints) and security (e.g. seccomp). It is also useful for advanced network security, performance profiling and dynamic tracing.

BPF was originally an acronym of Berkeley Packet Filter since the original classic BPF was used for packet capture tools for BSD. This eventually evolved into Extended BPF (eBPF), which was shortly afterwards renamed to just BPF (not an acronym). BPF should not be confused with packet filtering tools like iptables or netfilter, although BPF can be used to implement packet filtering tools.

BPF code may be either interpreted or compiled using a Just-In-Time (JIT) compiler. The Arch kernel is built with `CONFIG_BPF_JIT_ALWAYS_ON` which disables the BPF interpreter and forces all BPF to use JIT compilation. This makes it harder for an attacker to use BPF to escalate attacks that exploit SPECTRE-style vulnerabilities. See the kernel patch which introduced CONFIG_BPF_JIT_ALWAYS_ON for more details.

The kernel includes a hardening feature for JIT-compiled BPF which can mitigate some types of JIT spraying attacks at the cost of performance and the ability to trace and debug many BPF programs. It may be enabled by setting `net.core.bpf_jit_harden` to `1` (to enable hardening of unprivileged code) or `2` (to enable hardening of all code).

See the `net.core.bpf_*` settings in the kernel documentation for more details.

提示：* linux-hardened包 sets `net.core.bpf_jit_harden=2` by default rather than `0`.

- By default, BPF programs can be run even by unprivileged users. To change that behaviour set `kernel.unprivileged_bpf_disabled=1`[7].

### ptrace 的可调用范围

The ptrace(2) syscall provides a means by which one process (the "tracer") may observe and control the execution of another process (the "tracee"), and examine and change the tracee's memory and registers. `ptrace` is commonly used by debugging tools including gdb, strace, perf, reptyr and other debuggers. However, it also provides a means by which a malicious process can read data from and take control of other processes.

Arch enables the Yama LSM by default, which provides a `kernel.yama.ptrace_scope` kernel parameter. This parameter is set to `1` (restricted) by default which prevents tracers from performing a `ptrace` call on traces outside of a restricted scope unless the tracer is privileged or has the `CAP_SYS_PTRACE` capability. This is a significant improvement in security compared to the classic permissions. Without this module, there is no separation between processes running as the same user (in the absence of additional security layers such as pid_namespaces(7)).

注意：By default, you can still use tools which require `ptrace` by running them as privileged processes, e.g. using sudo.

If you do not need to use debugging tools, consider setting `kernel.yama.ptrace_scope` to `2` (admin-only) or `3` (no `ptrace` possible) to harden the system.

### 隐藏进程

这篇文章的某些内容需要扩充。

原因：Linux 5.8 implemented private instances and new values for `hidepid=`. (在 Talk:安全 中讨论)

本文或本章节的事实准确性存在争议。

原因： Enabling `hidepid` globally is not a supported way of operation by systemd, nor does it have any practical improvements security-wise when systemd is running as service manager. [8]（在 Talk:安全 中讨论）

警告：

- 这可能会导致某些应用程序出现问题，例如在沙盒和 Xorg 中运行的应用程序（请参阅解决方法）。
- 当所使用的 systemd包 版本大于 237.64-1 时，这可能会导致 D-Bus、PulseAudio 和 bluetooth 出现问题。

其他用户的进程通常可以在 `/proc` 访问到，而内核有能力向非特权用户隐藏这些进程，按照此处记录的方法以 `hidepid=` 和 `gid=` 选项挂载 `proc` 文件系统即可。

这使得入侵者收集正在运行的进程信息变得异常艰难，同样艰难的还包括判断是否存在特权运行的守护进程、其他用户是否正在运行敏感程序，甚至无法捕捉到其他用户运行的任何程序，更无法捕捉到特定的程序是否正在运行（假设该程序不会因为其自身行为暴露自己），并且作为额外的优势，那些通过外部参数传递敏感信息的、写得不那么好的程序现在可以防范本地窃听了。

由 filesystem包 软件包提供的 `proc` 用户组相当于一个白名单，包含了有权访问其他用户进程信息的用户。如果用户或服务需要访问除自身以外的 `/proc/<pid>` 目录，请将他们加入该用户组。

例如，把除了 `proc` 组中用户之外的其他用户的进程信息都隐藏起来：

    /etc/fstab

    proc	/proc	proc	nosuid,nodev,noexec,hidepid=2,gid=proc	0	0

要使用户会话正常工作，需要为 systemd-logind 添加例外：

    /etc/systemd/system/systemd-logind.service.d/hidepid.conf

    [Service]
    SupplementaryGroups=proc

### Restricting module loading

The default Arch kernel has `CONFIG_MODULE_SIG_ALL` enabled, which signs all kernel modules built as part of the linux包 package. This allows the kernel to only load modules signed with a valid key, i.e. out-of-tree modules compiled locally or provided by packages such as virtualbox-host-modules-arch包 cannot be loaded.

Kernel module loading can be restricted by setting the `module.sig_enforce=1` kernel parameter. More information can be found in the kernel documentation.

### Disable kexec

Kexec allows replacing the current running kernel.

    /etc/sysctl.d/51-kexec-restrict.conf

    kernel.kexec_load_disabled = 1

提示：kexec is disabled by default in linux-hardened包.

### Kernel lockdown mode

Since Linux 5.4 the kernel has gained an optional lockdown feature, intended to strengthen the boundary between UID 0 (root) and the kernel. When enabled some applications may cease to work which rely on low-level access to either hardware or the kernel.

To use lockdown, its LSM must be initialized and a lockdown mode must be set.

All officially supported kernels initialize the LSM, but none of them enforce any lockdown mode.

提示：Initialized LSMs can be verified by running `cat /sys/kernel/security/lsm`.

Lockdown has two modes of operation:

- `integrity`: kernel features that allow userland to modify the running kernel are disabled (kexec, bpf).
- `confidentiality`: kernel features that allow userland to extract confidential information from the kernel are also disabled.

It is recommended to use `integrity`, unless your specific threat model dictates otherwise.

To enable kernel lockdown at runtime, run:

    # echo mode > /sys/kernel/security/lockdown

To enable kernel lockdown on boot, use the kernel parameter `lockdown=mode`.

注意：

- Kernel lockdown cannot be disabled at runtime.
- Kernel lockdown disables hibernation.

See also kernel_lockdown(7).

### Linux Kernel Runtime Guard (LKRG)

LKRG (lkrg-dkmsAUR) is a kernel module which performs integrity checking of the kernel and detection of exploit attempts.

### Disable emergency shell

本文或本章节的事实准确性存在争议。

原因： Masking `emergency.target` and `emergency.service` will have no effect on those units being added to the initramfs and run in early userspace. Even with them in the initramfs, mkinitcpio's systemd hook locks the root account[9][10] for "security reasons" (see FS#70408). The solution for the issue in the linked article, if even needed, would be to prevent `rescue.target`, `rescue.service`, `emergency.target` and `emergency.service` from being added to the initramfs image.（在 Talk:安全 中讨论）

The emergency shell is used to interactively troubleshoot the machine during the boot process. However, it is also a gadget that an attacker can use to access secure resources such as the TPM. See this article for a practical example. The difficulty of attacks can be increased by disabling the emergency shell, at the tradeoff of removing a tool to troubleshoot early boot failures.

To disable the emergency shell, See Systemd#Disable emergency mode on remote machine.

## 沙盒程序

另请参阅 Wikipedia:Sandbox (computer security)。

注意：用户命名空间配置项 `CONFIG_USER_NS` 当前在 linux包（v4.14.5或更高版本）、linux-lts包（v4.14.15或更高版本）和 linux-hardened包 中启用。关闭它可能会导致程序无法开启某些沙盒功能。由于会增加本地提权的可能性，非特权用法默认是禁用的，启用它需要将 `kernel.unprivileged_userns_clone` sysctl 设置为 `1`。
警告：Unprivileged user namespace usage (`CONFIG_USER_NS_UNPRIVILEGED`) is enabled by default in linux包, linux-lts包 and linux-zen包, which greatly increases the attack surface for local privilege escalation (see FS#36969).

To mitigate this, either :

- use the linux-hardened包 kernel which has the safe default, or
- set the `kernel.unprivileged_userns_clone` sysctl to `0`.

Note that this can break applications such as Zoom. You will also need to replace bubblewrap包 with bubblewrap-suid包 if it is installed on your system. See Bubblewrap#Installation.

### Firejail

Firejail是一种易于使用的用于沙盒化应用程序和服务器的工具。它原本是为浏览器和面向互联网的应用程序创建的，但现在已经支持大量的应用程序。为了建立具有各种特性的沙盒环境，它被安装为一个suid二进制文件，并根据黑名单和白名单为目标应用程序构建一个沙盒化的运行时环境。

### bubblewrap

bubblewrap 是为无特权容器工具（如 Flatpak）开发的沙箱应用程序，其资源占用和复杂性都远远小于Firejail。虽然它缺少某些功能，如文件路径白名单，但bubblewrap确实提供了bind挂载以及创建用户/IPC/PID/网络/cgroup命名空间的功能，并且可以支持简单和复杂的沙箱。

Bubblejail沙箱基于bubblewrap，并提供了一个面向资源的权限模型，用户可以通过图形界面进行权限的调整。

### chroots

也可以手动构建chroot囚禁来创建沙箱化的进程环境。其相比其他沙箱技术的功能有限；它的沙箱程度仅限于文件路径隔离。

### Linux容器

当你需要比其他选项提供的更多分离时（简略于 #完全虚拟化选项) ，Linux Containers是另一个很好的选择。LXC在现有内核之上运行，采用伪chroot，并拥有自己的虚拟硬件。

### 完全虚拟化选项

如果你计划运行风险应用程序或浏览危险网站，使用完全虚拟化选项如VirtualBox，KVM，Xen或 Qubes OS (基于Xen)也可以提高隔离和安全性。

## 网络与防火墙

### 防火墙

虽然源里面的 Arch 内核能够启用 Netfilter 的 iptables 和 nftables，但它们默认是关闭的。因此强烈建议配置防火墙来保护系统上运行的服务。许多资料（包括 ArchWiki）没有明确说明哪些服务值得保护，因此启用防火墙是一个很好的预防措施。

- 参阅 iptables 和 nftables 来获取一般信息。
- 参阅 Simple stateful firewall 来获取配置 iptables 防火墙的指南。
- 参阅 Category:Firewalls 来获取设置 netfilter 的其他方法。
- 参阅 Ipset 以设置 IP 地址黑名单，内容可参考来自 Bluetack 的名单。
- opensnitch包 是一个可配置的入站和出站防火墙，支持按应用程序、端口、主机等进行规则配置。

### Open ports

本文或本章节的语言、语法或风格需要改进。参考：帮助:风格

原因："Open ports" is not a good title since it disregards interfaces and addresses that the application may be bound to. From the firewalls' point of view, ports may be "open" even if no application listens on them at the moment.（在Talk:安全讨论）

一些服务会在开放的网络端口上监听入站流量。只将这些服务绑定到严格必要的地址和接口是非常重要的。远程攻击者可能能够利用有缺陷的网络协议访问暴露的服务。即使在绑定到localhost的进程中，这种情况也可能发生。

总的来说，如果一个服务只需要对本地系统可访问，那么就绑定到一个Unix域套接字 (unix(7))或者一个回环地址，比如`localhost`，而不是非回环地址，比如`0.0.0.0/0`。

如果一个服务需要通过网络对其他系统可访问，那么就通过严格的防火墙规则控制访问，并且尽可能配置认证、授权和加密。

你可以使用`ss -l`来列出所有当前开放的端口。要显示所有正在监听的进程及其数值化的 tcp 和 udp 端口号：

    # ss -lpntu

查看 ss(8) 以获取更多选项。

### 内核参数

作用于网络的内核参数可以使用 Sysctl 来设置。要查询具体方法，请参阅 Sysctl#TCP/IP stack hardening。

### SSH

为了减轻暴力攻击，建议强制使用基于密钥的身份验证。对于 OpenSSH，请参阅 OpenSSH#Force public key authentication。另外，Fail2ban 或 Sshguard 通过监控日志并写入 iptables 规则提供了较少形式的保护，但这样做可能会使服务器拒绝服务，因为攻击者可以伪装成管理员的地址并发送欺骗性的数据包。

你可以用双因素身份验证来进一步强化身份验证。Google Authenticator（Google 身份验证器）使用一次性密码 (OTP) 提供两步验证过程。

拒绝 root 登录也是一种很好的做法，既可以跟踪入侵，也可以在 root 访问之前添加额外的安全层。对于 OpenSSH，请参阅 OpenSSH#Deny。

Mozilla公开发布了一个OpenSSH配置指南，其中设置了更为详尽的审计日志记录，并限制了密码。

### DNS

默认的域名解析（DNS）配置具有很高的兼容性，但存在安全弱点。查看域名解析#隐私与安全获得更多信息。

### 代理

代理通常用作应用程序和网络之间的额外层，对来自不可信来源的数据进行清理。从攻击面上看，一个以较低权限运行的小型代理的攻击面显著小于以最终用户权限运行的复杂应用程序。

例如，DNS解析器在glibc包中实现，该解析器与应用程序（可能以root身份运行）链接，因此DNS解析器中的错误可能导致远程代码执行。通过安装DNS缓存服务器，例如dnsmasq，它可以起到代理的作用，可以防止这种情况发生。[11]

### 管理TLS证书

请查看 TLS#信任管理。

## 物理安全

只要有足够的时间和资源，对计算机的物理访问就等同于 root 权限的访问。然而，通过设置足够的障碍，可以获得较高的实际安全级别。

攻击者可以通过简单地连接一个恶意的IEEE 1394（FireWire）、雷电或PCI Express设备，即可在下次启动时完全控制您的计算机，因为这些设备默认被赋予全内存访问权限。[12] 对于雷电，您可以完全限制直接内存访问或仅限于已知设备，参见雷电#用户设备授权。对于Firewire和PCI Express，防止此类事件或硬件自身的修改（例如在驱动器上刷新恶意固件）您能做的很少。但是，大多数攻击者并非这么有知识和决心。

#静态数据加密可以防止计算机被盗时对您的数据的访问，但是资源充足的攻击者可以安装恶意固件，在您下次登录时获取此数据。

### 锁定BIOS

在BIOS中添加密码可以防止他人启动至可移动媒体，这基本上相当于对您的计算机拥有根访问权限。您应确保您的驱动程序在启动顺序中排在第一，并尽可能禁用其他驱动程序的启动功能。

### 引导加载程序 (Bootloader)

保护您的引导加载程序非常重要。一个未受保护的启动加载器可以绕过任何登录限制：例如通过设置`init=/bin/sh`内核参数以直接启动到shell，它会使得任何用户的登录限制完全无用。

#### Syslinux

Syslinux支持对启动加载器进行密码保护。它允许您设置菜单项密码 或者 全局启动加载器密码。

#### GRUB

GRUB也支持启动加载器密码。请查看GRUB/技巧和窍门#用密码保护 GRUB 菜单以获取详细信息。它还支持 #加密的/boot，这可以加密GRUB的配置，内核和 initramfs ，只剩下启动加载器代码中的一部分未加密。

#### systemd-boot

当启用#安全启动时，systemd-boot禁止编辑内核参数。另外，参见 systemd-boot#带密码保护的内核参数编辑器以获得更传统的基于密码的选项。

### 安全启动

安全启动是UEFI的功能，允许验证你的计算机启动的文件。这有助于防止一些邪恶女仆攻击，如替换启动分区内的文件。通常，计算机会携带由供应商（OEM）授予的密钥，不过，密钥可以被删除，并使计算机进入设置模式，允许用户导入并管理自己的密钥。

安全启动页面会引导你如何通过使用自己的密钥来设置安全启动。

### 可信平台模块 (TPM)

TPMs 是带有嵌入式加密密钥的硬件微处理器。这构成了大多数现代电脑的基本信任根（源），允许对启动链执行端到端验证。它们可用作内部智能卡，验证计算机上运行的固件，并允许用户将密码插入防篡改和抗暴力破解的存储器中。

### 在可移动闪存驱动器上的启动分区

一个流行的想法是将启动分区放在闪存驱动器上，以便在没有它的情况下系统无法启动。提倡这个想法的人通常会使用全盘加密，有些人还会使用放在启动分区的分离的加密头。

### 自动注销

如果您使用Bash或Zsh，您可以设置 `TMOUT` 在超时后自动从shell注销。

例如，以下操作将在虚拟控制台（但不是X11中的终端模拟器）自动退出：

    /etc/profile.d/shell-timeout.sh

    TMOUT="$(( 60*10 ))";
    [ -z "$DISPLAY" ] && export TMOUT;
    case $( /usr/bin/tty ) in
        /dev/tty[0-9]*) export TMOUT;;
    esac

如果你确实希望每一个Bash/Zsh提示符（甚至在X内）都有超时，使用：

    $ export TMOUT="$(( 60*10 ))";

注意，如果有一些命令在shell中运行（例如：一个SSH会话或没有`TMOUT`支持的其他shell），这将不起作用。但是，如果你主要是用VC来重启冷冻的GDM/Xorg作为root，那么这会非常有用。

### 保护免受恶意USB设备的攻击

安装 USBGuard，这是一个软件框架，可以通过实现基于设备属性的基本白名单和黑名单功能，帮助保护你的计算机免受恶意USB设备的攻击（也称为 BadUSB、PoisonTap 或 LanTurtle）。

### 易失性数据收集

开启状态的计算机可能会受到易失性数据收集的威胁。将计算机完全关闭，在无需使用时或者计算机的物理安全暂时受到破坏时（例如，通过安全检查点），是一种最好的做法。

## 软件包

### 验证

如果没有正确地对包进行签名，包管理器就有可能受到攻击，甚至可能会影响原本具有签名机制的包管理器。Arch 默认采用软件包签名机制，并依赖与 5 个受信任的主密钥的信任网络。详情请参阅 pacman/Package signing。

### 升级

定期升级系统非常重要。

### 关注漏洞警报

可订阅由国家漏洞数据库提供的Common Vulnerabilities and Exposure（CVE）安全警报更新，在NVD Download网页上可以找到。Arch Linux安全跟踪器将Arch Linux安全顾问（ASA）、Arch Linux漏洞小组（AVG）和CVE数据集合并在一张表格中，因此是非常有用的资源。该工具arch-audit包可以用来检查影响当前运行系统的漏洞。也可以使用图形化的系统托盘arch-audit-gtk包。另请参见Arch 安全团队。

如果您通过主要仓库或AUR之外的其他方式安装软件，您还应考虑订阅您使用的软件的 发布通知。一些软件有您可以订阅的安全通知邮件列表。源代码托管网站通常提供可以接收新版本发布消息的RSS源。

### 重新构建软件包

软件包可以去除不需要的功能并重新构建，这样可以缩小受攻击范围。例如，bzip2包 可以在没有 `bzip2recover` 的情况下重新构建，以试图规避 CVE-2016-3189 漏洞。强化安全的自定义编译参数也可以手动或通过包装器在编译时加入。

本文或本章节可能需要合并到Arch package guidelines/Security。

附注： Security related build flags have their own article.（在 Talk:安全 中讨论）

本文或本章节的事实准确性存在争议。

原因： 复制粘贴自从 3 年前的博客文章。编译器标志特定于 GCC，有些几乎与安全无关(例如 `-O2`, `-g`, `-Wall`).（在 Talk:安全 中讨论）

Flag | Purpose
--- | ---
-D_FORTIFY_SOURCE=2 | Run-time buffer overflow detection
-D_GLIBCXX_ASSERTIONS | Run-time bounds checking for C++ strings and containers
-fasynchronous-unwind-tables | Increased reliability of backtraces
-fexceptions | Enable table-based thread cancellation
-fpie -Wl,-pie | Full ASLR for executables
-fpic -shared | No text relocations for shared libraries
-fplugin=annobin | Generate data for hardening quality control
-fstack-clash-protection | Increased reliability of stack overflow detection
-fstack-protector or -fstack-protector-all | Stack smashing protector
-fstack-protector-strong | Likewise
-g | Generate debugging information
-grecord-gcc-switches | Store compiler flags in debugging information
-mcet -fcf-protection | Control flow integrity protection
-O2 | Recommended optimizations
-pipe | Avoid temporary files, speeding up builds
-Wall | Recommended compiler warnings
-Werror=format-security | Reject potentially unsafe format string arguments
-Werror=implicit-function-declaration | Reject missing function prototypes
-Wl,-z,defs | Detect and reject underlinking
-Wl,-z,now | Disable lazy binding
-Wl,-z,relro | Read-only segments after relocation

- Flags and info source

## 参考资料

- unixchad 的视频：《捍卫隐私的真正方法：Firejail，全盘加密，GPG和ufw》
- Arch Linux Security Tracker
- CentOS Wiki: OS Protection
- Hardening the Linux desktop
- Hardening the Linux server
- Linux Foundation: Linux workstation security checklist
- privacytools.io Privacy Resources
- Red Hat Enterprise Linux 7 Security Guide
- Securing Debian Manual
- The paranoid #! Security Guide

1. ↑ https://math.ucr.edu/~mike/zipattacks.pdf

分类：​

- 安全
- 文件系统
- 网络
- 使用“模板:风格”标记的页面或章节

隐藏分类：​

- 使用“模板:准确性”标记的页面或章节
- 使用“模板:合并”标记的页面或章节

安全
添加话题