Update linux-desktop.html

collections/_evergreen/linux-desktop.html

@@ -180,6 +180,10 @@ <h5>Mountpoint hardening</h5>
 If you use <a href="https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/">Toolbox</a>, <code>/var/log/journal</code> must not have any of those options.
 If you are on Arch Linux, do not apply <code>noexec</code> to <code>/var/tmp</code>.
 
+<h5>PAM</h5>
+<p>Consider following section <a href="https://madaidans-insecurities.github.io/guides/linux-hardening.html#pam">14</a> on <a href="https://madaidans-insecurities.github.io/guides/linux-hardening.html#pam">Madaidan's hardening guide.</a></p>
+<p>On systems where pam_faillock is not available, consider using <a href="https://access.redhat.com/solutions/37687">pam_tally2</a> instead.</p>
+
 <h5>USBGuard</h5>
 <p>Consider following the <a href="https://wiki.archlinux.org/title/USBGuard">Arch Wiki</a> to set up USBGuard.</p>
 
@@ -189,4 +193,4 @@ <h5>Keystroke anonymization</h5>
 <h5>Physical security</h5>
 <p>Consider following section <a href="https://madaidans-insecurities.github.io/guides/linux-hardening.html#physical-security">21</a> on Madaidan's <a href="https://madaians-insecurities.github.io/guides/linux-hardening.html#identifiers">hardening guide</a>.</p>
 <p>By default, UEFI secure boot on Linux distributions is rather in effective. Besides the problems mentioned in Madaidan's guide as only the chainloader (shim), the boot loader (GRUB), and the kernel are verified. The initramfs is often left unverified, unencrypted, and open up the window for an <a href="https://en.wikipedia.org/wiki/Evil_maid_attack">evil maid</a> attack.</p>
-<p>This problem could be reduced by either <a href="https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot">combinding the kernel, initramfs, and microcode</a> into a signed EFI stub or by encrypting the <code>/boot</code> partition. If you are using openSUSE, your <code>/boot</code> partition should be encrypted by default should you enable drive encrytion.</p>
+<p>This problem could be reduced by either <a href="https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot">combinding the kernel, initramfs, and microcode</a> into a signed EFI stub or by encrypting the <code>/boot</code> partition. If you are using openSUSE, your <code>/boot</code> partition should be encrypted by default should you enable drive encrytion.</p>