安全

翻譯狀態：

• 本文（或部分內容）是 Security 的翻譯，最近一次同步的日期是 2024-01-20，如果英文版本有所更改，則您可以幫助同步翻譯更改的內容。
• 您可以在ArchWiki 的對應頁面找到本文翻譯的原始編輯記錄和貢獻者列表。

相關文章

• Arch 安全團隊
• 建議閱讀
• 認證管理
• Capabilities
• 應用程式列表/安全

本文包含了加固 Arch Linux 系統的常用建議與最佳實踐。

概念

• 收緊安全措施有可能達到使系統無法使用的程度。安全性與便利性需要得到平衡。訣竅在於建立一個安全且有用的系統。
• 最大的威脅是（並且一直都會是）用戶。
• 最小權限原則：系統的每一部分應該只能訪問到它確實需要的東西，除此之外的則不可以。
• 縱深防禦：多個獨立的層次能帶來更好的安全性。當一層防護被攻破時，另一層應該能夠阻止攻擊。
• 保持一點點的偏執和多疑。如果有件事看起來太好了，不像是真的，那可能確實如此。
• 永遠無法令系統 100% 安全，除非把機器從網絡上斷開，關掉電源，鎖進保險柜，用混凝土封住並不再使用它。
• 為失敗做好準備。預先為安全措施被攻破的情況制定可供執行的計劃。

密碼

密碼是一個安全系統的關鍵。它可以保護你的用戶賬戶、加密的文件系統和 SSH/GPG 密鑰。密碼也是讓計算機信任使用者的主要方式，所以安全性的很大一部分就在於選擇高強度的密碼並保護它們不被泄露。

選擇安全的密碼

密碼必須足夠複雜，不能輕易地被猜中（比如和個人信息有關的密碼），也不能輕易地被社會工程或暴力嘗試等方法 破解。強密碼的要點在於 長度 和 隨機性。在密碼學中，密碼的質量被稱為它的 熵安全性 。

不安全的密碼包括：

• 個人可識別信息（如：狗的名字，出生日期，區號，最喜歡的視頻遊戲）
• 對單詞簡單地替換一些字符（如：k1araj0hns0n），因為現代字典攻擊可以輕鬆對付它們
• 在基本單詞或常見字符串的前後加上數字，符號或其他字符（如：DG091101%）
• 常見句子或詞典中單詞的序列（如：photocopyhauntbranchexpose），包括對其字符進行替換（如：Ph0toc0pyh4uN7br@nch3xp*se）
• 任何一個最常見的密碼

最好的選擇是由隨機來源生成的長密碼（越長越好）。使用長密碼很重要。弱哈希算法會使得一個8字符密碼的哈希值在幾小時之內便被攻破。

像 pwgen^包 或 apg^AUR 這樣的工具可生成隨機密碼，不過這些密碼可能很難記住：為了記住它們，一種方法（僅針對經常使用的密碼）是生成一個長密碼並記住一小段（這一小段要能保證最低限度的安全），暫時把完整的密碼寫下來。在一次次的密碼輸入過程中，嘗試着記住從一小段到一大段乃至全部密碼，隨着時間推移，密碼就會隨着肌肉記憶根深蒂固。這種方法很難，但是能保證密碼不會出現在破解用的字典裡，也可以抵禦「智能地」組合單詞並替換部分字符的暴力破解手段。

Apart from password management, keepassxc^包 offers password/passphrase generation. It is possible to customize the generation in a GUI. Dictionary based passphrases are also supported.

還有個方法可以產生安全性好的、看起來隨機的密碼，那就是從一句句子的每一個詞中提煉出一個符號。 例如 「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）。

如果要備份密碼數據庫，請勿將備份的副本存儲在密碼保護之下（比如存儲在加密的驅動器或需要身份驗證的遠程存儲服務），而解鎖副本的密碼又存儲在副本中，這樣在需要時將無法訪問它（相當於把房間的鑰匙鎖在了房間裏）。一個有用的技巧是，使用主密碼的簡單哈希來加密存儲密碼數據庫的驅動器或帳戶。維護一份記錄備份位置的列表：如果有一天你覺得主密碼已被泄露，一是要更改所有數據庫備份的密碼，二是要使用從新主密碼派生的新哈希來保護存有數據庫的位置。

以安全的方式控制數據庫的版本可能非常複雜：如果你這樣做，那你必須有辦法更新所有數據庫版本的主密碼。主密碼泄露時，你可能並不能馬上知道：為了降低其他人在你意識到主密碼泄露之前發現密碼的風險，你可以選擇定期更改主密碼。如果你擔心自己失去了對數據庫副本的控制權，則需要根據主密碼的熵，在暴力破解主密碼所需的時間內更改數據庫副本中包含的所有密碼。

密碼的散列值

默認情況下，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

內存

Hardened malloc

hardened_malloc (hardened_malloc^AUR, hardened-malloc-git^AUR) is a hardened replacement for glibc's malloc(). The project was originally developed for integration into Android's Bionic and musl by Daniel Micay, of GrapheneOS, but he has also built in support for standard Linux distributions on the x86_64 architecture.

While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in /etc/ld.so.preload. Since hardened_malloc has a performance cost, you may want to decide which implementation to use on a case-by-case basis based on attack surface and performance needs.

To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:

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

Proper usage with Firejail can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.

存儲

靜態數據加密

靜態數據加密，最好是使用強密碼的全磁盤加密，是保護數據免受物理恢復的唯一方法。這在計算機關閉或相關磁盤卸載時提供了數據機密性。

然而，一旦計算機啟動並且驅動器被掛載，其數據將變得與未加密的驅動器一樣容易受到攻擊。因此，最佳做法是在不再需要數據分區時立即卸載它們。

你還可以使用存儲在 TPM 中的密鑰對驅動器進行加密，儘管它過去存在可以通過總線嗅探攻擊提取密鑰的漏洞。

某些程序，如 dm-crypt，允許用戶將 Loop file 加密為虛擬卷。當系統只有特定的部分需要加密時，這種方法可以替代全盤加密。

雖然 數據靜態加密wiki 中比較的基於塊設備或文件系統的加密類型對於保護物理媒體上的數據很有用，但大多數不能用於保護無法控制的遠程系統上的數據（例如雲存儲）。在某些情況下，個別文件加密會很有用。

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

• 一些歸檔和壓縮工具還提供基本的加密功能。一些示例是 p7zip（ -p 標誌）、zip^包（ -e 標誌）。加密時要特別小心，因為這些工具可能使用自定義算法來實現跨平台兼容性。
• 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掛載選項。

文件訪問權限

默認的 文件權限 對幾乎所有文件都賦予了讀權限，修改文件權限可以在取得了非 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"

備份

定期創建重要數據的備份。定期測試備份的完整性。定期測試備份是否可以恢復。

確保至少一份數據副本離線存儲，即不以任何方式連接到存在威脅的系統。勒索軟件和其他破壞性攻擊也可能攻擊任何連接的備份系統。

參見 系統備份。

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 進行特權訪問比 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 登錄。這樣做的目的是在用戶可以在遠程完全破壞系統之前添加額外的一層安全保護。

Specify acceptable login combinations with access.conf

When someone attempts to log in with PAM, /etc/security/access.conf is checked for the first combination that matches their login properties. Their attempt then fails or succeeds based on the rule for that combination.

+:root:LOCAL
-:root:ALL

Rules can be set for specific groups and users. In this example, the user archie is allowed to login locally, as are all users in the wheel and adm groups. All other logins are rejected:

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

Read more at 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-bin^AUR
• 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.

隱藏進程

警告：

• 這可能會導致某些應用程式出現問題，例如在沙盒和 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-dkms^AUR) is a kernel module which performs integrity checking of the kernel and detection of exploit attempts.

Disable emergency shell

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

一些服務會在開放的網絡端口上監聽入站流量。只將這些服務綁定到嚴格必要的地址和接口是非常重要的。遠程攻擊者可能能夠利用有缺陷的網絡協議訪問暴露的服務。即使在綁定到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 是帶有嵌入式加密密鑰的硬件微處理器。這構成了大多數現代電腦的基本信任根（源），允許對啟動鏈執行端到端驗證。它們可用作內部智能卡，驗證計算機上運行的固件，並允許用戶將密碼插入防篡改和抗暴力破解的存儲器中。

在可移動閃存驅動器上的啟動分區

一個流行的想法是將啟動分區放在閃存驅動器上，以便在沒有它的情況下系統無法啟動。提倡這個想法的人通常會使用全盤加密，有些人還會使用放在啟動分區的分離的加密頭。

這種方法也可以與加密 /boot合併。

自動註銷

如果您使用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 漏洞。強化安全的自定義編譯參數也可以手動或通過包裝器在編譯時加入。

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

參考資料

• 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