Leserartikel [How-To] Arch Linux installieren (verschlüsselt, gehärtet, spieletauglich, modular)

[agon]

@csch92 Das meiste aus dem Setup Guide bezieht sich nicht auf die Installation von Arch Linux.
Es werden eben auch Themen wie:

• UEFI-Einstellungen
• Windows-Kompatibilität
• Prüfen der "Gesundheit" der SSD/HDD
• Ändern der Sector/Page size der SSD/HDD für bessere Leistung
• Audio Latenz-Optimierung anhand der eigenen Hardware
• und vieles mehr

behandelt.

Da sind einige Schritte dabei, die eine Distro normalerweise nicht beachtet, wenn v.a. manuelles Eingreifen bzw. eigenes Wissen erforderlich ist.
Und dennoch kannst du jenes auf jeder x-beliebigen Distro anwenden.

 

[agon]

Changelog​

• Validated installation procedure up to and including chapter 9
  • Update: Small fixes & improvements
• Overhaul: Trusted Platform Module (TPM2)
  … using the reworked systemd 262 implementation, see "Changes in the TPM Subsystem"
  … for measured boot & disk decryption using TPM2 PIN w/ lower entropy.
  It is recommended that you follow these steps. Also to fix the TPM errors.
• Update: Snapper
  • New: For KDE: Integration of snapshots of the user's home
    … using KIO Snapshot
    … if you are snapshotting your home too
  • Update: Shortened snapper commands

If you like to support my work, you can that by donating e.g. ComputerBase Pro.

 

[Spike S.]

Wenn ich das richtig sehe, reicht Kapitel 5.10.1 um den neuerlichen TPM Fehler beim Boot wegzubekommen?

Dieser Kombination aus PIN+TPM2 (hat man ja auch bei Windows Hello) traue ich noch nicht so richtig. Bei meinem Heimrechner sehe ich da eher eine Schwächung. Denn wenn jemand die Festplatte in die Hände bekommt (Dieb), dann ja im ganzen Rechner komplett, inkl. dem TPM2.

Nachfrage: Für den measured boot, warum nicht einfach beim systemd-cryptenroll den Parameter --tpm2-pcrs= angeben? Auf die Frage bin ich nach einem Frage-Antwort-Spielchen mit einem künstlichen neuronalen Netzwerk gekommen. Im Standard bindet cryptenroll an keine PCRs.

 

[agon]

Wenn ich das richtig sehe, reicht Kapitel 5.10.1 um den neuerlichen TPM Fehler beim Boot wegzubekommen?

Nur die neuen Fehler, aber nicht den Fehler "systemd-cryptsetup: No valid TPM2 token data found."

Denn wenn jemand die Festplatte in die Hände bekommt (Dieb), dann ja im ganzen Rechner komplett, inkl. dem TPM2.

Dazu meine Info: Initially, you have 4 attempts to enter the TPM2 PIN, otherwise you can enter the passphrase
or the recovery key to decrypt the volume. If your attempts failed, TPM2 may go into dictionary
attack lock-out mode with reduced attempts.

TPM dient hier als 2FA. Wenn der Dieb die schwächere PIN nicht nach wenigen Versuchen richtig eingibt, muss dieser die stärkere Passphrase oder Recovery-Key herausfinden. Sprich, er wird die SSD/HDD ausbauen und bspw. den John the Ripper password cracker benutzen.

Und als Nutzer möchte man nicht unbedingt ein "langes & schweres" Passwort beim Booten jedes mal eingeben.

Für den measured boot, warum nicht einfach beim systemd-cryptenroll den Parameter --tpm2-pcrs= angeben?

Aus dem Arch Wiki:
"With TPM2 it is possible to bind secrets, like the LUKS root decryption key, to a signed policy rather than raw PCR values. These policies add flexibility by allowing PCR values to vary, provided there is a valid PCR signature for these values which matches the public key enrolled with the secret. For instance, rather than simply tying the encryption key to the PCR7 value (which only checks that Secure Boot has not been disabled or tampered with) you can bind it to a PCR policy that verifies the booting of a known Unified kernel image (UKI), with all its components measured during the boot process. See systemd-cryptenroll(1) § TPM2 PCRs and policies."
Ein Secure Boot DBX Update ändert übrigens den PCR7-Wert.

Mit der Policy funktioniert standardmäßig die TPM PIN auch ohne Secure Boot.

 

[Spike S.]

Ich hatte bis vor zwei Wochen keine TPM Fehler, daher hatte 5.10.1 gereicht. Hatte aber noch 5.4 (Kernelsignierung) nachgeholt, bei der Gelegenheit.
Für TPM2 muss ich erstmal schauen, ob mein Board das hat und ob es aktiviert ist. Werde es dann aber noch umsetzen, falls ich TPM2 habe. Ja, das Modul ratelimited ja recht stark von selbst aus. Die LUKS Passworteingabe bremst vermutlich auch, nach einigen Fehlversuchen? Hatte es noch nie drauf ankommen lassen müssen

Mit den signed PCRs ist das dann also ein neuerer, "smarterer" Weg. Mit den alten PCRs direkt als Parameter, warnte mich die KI auch, dass das schnell fragil wird, bei zu vielen davon. Ein BIOS Update und ein neuer Kernel (je nach Auswahl natürlich) und schwupps, wird es nicht mehr akzeptiert.
Ich sehe es nur für mich als Heimanwender, nicht so gewinnbringend. Wenn man mir die Technik klaut, dann den ganzen Rechner inklusive Boot-Pfad. Und das ist äußerst unwahrscheinlich, das der Dieb dann mehr versucht, als mal kurz booten um zu gucken ob man was findet. Geht nicht, platt machen, verkaufen. Bin ja keine Person of interest.
Werde es aber früher oder später trotzdem einrichten, einfach weil man es kann

Danke für deine wiederkehrenden Updates zu dem Build und den Neuentwicklungen

 

[agon]

Changelog​

• Removed: Also snapshot the ESP
  And in "Restoring / (subvolume @) to its previous snapshot", the UKIs will be generated in chroot now. So remove the hook & backups:
  # rm /etc/pacman.d/hooks/95-efibackup.hook; rm -rf /.efibackup/;
• Update: Automount keyfile encrypted disk
  System startup time is reduced because the system does not wait for the drive to mount
• Removed: Steam > Update default compatibility tool (yearly)
  … since Proton Experimental is now the default tool
• New: More Kernel Hardening > Disable kexec
  This is also required by EAC Linux v2

---

• Info: EAC Linux v2 with own Secure Boot keys will not work, even though all other requirements are met – as of now
• Current workaround for Steam + firejail users, see #7268:
  # /etc/firejail/steam.profile > Append:
  seccomp !chroot,!mount,!name_to_handle_at,!pivot_root,!process_vm_readv,!ptrace,!umount2,!mount_setattr
• News: Linux Patches Finally Make Hibernation Possible In Secure Boot / Lockdown Mode
• News: keepassxc 2.8 transitioned to Qt 6 -> QT 5 will be removed soon
• News: The Steam client is now a 64bit application -> Multilib will be removed soon

 

[Spike S.]

KeepassXC 2.8 ist da und es gibt eine Änderung in der Konfiguration die wegen Firejail relevant ist. Die keepassxc.ini die unter ~/.cache/keepassxc lag und sich Einstellungen und letzte Datenbank gemerkt hatte gibt es nicht mehr. Stattdessen wird das jetzt unter ~/.local/state/keepassrc gespeichert (Config.cpp migriert von Cache nach XDG_STATE_HOME).
Man muss also entsprechende Einträge in seiner keepassxc.local hinzufügen (und die alten .cache löschen)

mkdir ${HOME}/.local/state/keepassxc
whitelist ${HOME}/.local/state/keepassxc
whitelist ${HOME}/.local/state/KeePassXCstaterc

 

[agon]

firejail v0.9.82 ist nun in den Arch Repos mit den KeePassXC & Steam Fixes.

Spoiler: keepassxc.local

# Enable Whitelisting
## NOTE: You MUST store your database in ~/Documents/KeePassXC/<foo.kdbx>
mkdir ${HOME}/Documents/KeePassXC
whitelist ${HOME}/Documents/KeePassXC

## FireFox
mkdir ${HOME}/.config/mozilla/native-messaging-hosts
mkdir ${HOME}/.mozilla/native-messaging-hosts
mkfile ${HOME}/.config/mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json
mkfile ${HOME}/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json
whitelist ${HOME}/.config/mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json
whitelist ${HOME}/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json

## Basic
mkdir ${HOME}/.cache/keepassxc
mkdir ${HOME}/.config/keepassxc
mkdir ${HOME}/.local/state/keepassxc
whitelist ${HOME}/.cache/keepassxc
whitelist ${HOME}/.config/keepassxc
whitelist ${HOME}/.config/KeePassXCrc
whitelist ${HOME}/.local/state/keepassxc
include whitelist-common.inc


# Hardware Security Key (Nitrokey, YubiKey)
ignore private-dev
# Allow access to pcscd socket (Smartcards)
whitelist /run/pcscd

 

[Spike S.]

@agon Weil ich gerade wieder deine "kurze" keepassxc.local sehe, Autostart (zumindest nicht aus KeepassXC heraus aktiviert) und Tray Icon nutzt du nicht? Den SSH-Agent auch nicht.
Weil, ohne Einträge zu diesen drei Themen funktionieren die alle nicht bei mir. Ich habe aber irgendwie im Hinterkopf, Tray Icon hast du trotzdem?

 

[Spike S.]

Ich lass mal meine zusätzlichen optionalen QoL Einstellungen da. Für das Auto-Type unter Wayland (geht mit 2.8 endlich), braucht es auch einen Eintrag in der .local. Autostart habe ich auskommentiert, weil ich mir dachte damit kann man im schlimmsten Fall mir eine Überraschung beim nächsten Systemstart bereiten. Daher nutze ich doch lieber den System Autostart in den Systemeinstellungen.

## Autostart ("Beim Systemstart starten" in den Einstellungen)
## disable-common.inc blacklistet ${HOME}/.config/autostart, blacklist gewinnt gegen whitelist -> noblacklist ist zwingend.
#noblacklist ${HOME}/.config/autostart
#mkdir ${HOME}/.config/autostart
#whitelist ${HOME}/.config/autostart

## Tray icon
dbus-user.talk org.kde.StatusNotifierWatcher

## Auto-Type unter Wayland (XDG RemoteDesktop Portal)
## Muss nach "dbus-user filter" aus dem Hauptprofil stehen, deshalb hier.
dbus-user.talk org.freedesktop.portal.Desktop

# SSH: KeePassXC schiebt die Keys nur ueber den Agent-Socket in den bereits laufenden ssh-agent (SSHAgent.cpp).
# ssh-agent.socket via systemd liegt in $XDG_RUNTIME_DIR (nicht mehr /tmp/ssh-*). Für Flatpak-Anwendungen wird ein Legacy-Pfad zusätzlich benötigt.
whitelist ${RUNUSER}/ssh-agent.socket

 

[agon]

@Spike S. Ich benutze KeePassXC nicht übermäßig oft, da benötige ich keinen Autostart. Autostart über KDE reicht ja, was du ja auch so gemacht hast.

Ich kenne die Features nicht, die ein Tray-Icon bietet. Du kannst übrigens auch generell Tray-Icons erlauben in der

/etc/firejail/firejail.config:
# Allow programs to display a tray icon (warning: allows escaping the sandbox;
# see https://github.com/netblue30/firejail/discussions/4053)
# allow-tray no

Für SSH benutze ich meine FIDO2-Keys (Nitrokeys). Der private Schlüssel verlässt dabei auch nicht das Gerät. Ideal für wichtige Dienste.

Auto-Type benötigt man doch nicht, wenn man schon die Erweiterung installiert hat(?)

 

[Spike S.]

Achso, Gelegenheitsnutzer
Ich brauche immer irgendwas aus der Keepass DB, entweder um auf meine Server zu kommen (SSH bim Unlock in den Agenten laden ist da praktisch) oder für irgendwelche Seiten zur Anmeldung. Das Tray Icon ist tatsächlich nur zum direkten öffnen von KeepassXC mit einem Klick da. Ich lasse es minimiert starten, da hilft das Klicks zu sparen.

Auto-Type benötige ich in seltenen Gelegenheiten, in denen ich per VNC auf meine Server muss. Da kann man nichts aus der Zwischenablage einfügen, aber die simulierten Tastendrücke klappen. Und bei den Browsern wäre es dann egal, ob die die Erweiterung haben oder nicht, aber das kann jeder halten wie er/sie will.

Ich habe auch erst einen Nitrokey, da fehlt für den täglichen Gebrauch mindestens einer als Backup. Ich bilde mir ein, zum Black Friday gab es die immer mal reduziert, darauf warte ich aktuell noch.

 

[agon]

Ich habe mir auch erst ein Jahr später den 2. Nitrokey geholt. Zum Black Friday gibt es 10%.
SSH über FIDO2 ist aber relativ einfach. FIDO-PIN eingeben (User Verification) und optional antippen (User Presence), und man ist drinnen.

Ich muss wohl noch den Artikel zu Nitrokey überarbeiten mit zweitem Nitrokey. Habe mal etwas recherchiert, v.a. zu den Einsatzmöglichkeiten. Denn der Hauptzweck von OpenPGP ist wohl v.a. Verschlüsseln von Dateien und Mails.
Den Rest kann man mit FIDO2 machen, also:

• Login:
  • WebAuthn/Passkeys
  • SSH Key
  • Using a FIDO2 authenticator for local login
  • Evtl. KeePassXC mit der FIDO2 hmac-secret extension
• Signieren von Dateien & Git signing

Bin am überlegen, ob man den OpenPGP-Abschnitt wirklich so ausführlich benötigt. Schlussendlich kann man den privaten Schlüssel von seinem Mailbox-Provider herunterladen und in den Nitrokey importieren. Ist schlussendlich nur für einen Email-Client interessant.

 

[Spike S.]

Ich fände es nicht schlecht, all die Möglichkeiten mal an einem Fleck zu haben. Wenn man nach dem Thema FIDO2 und PGP sucht, findet man doch meist nur Artikel, die nur einzelne Punkte von all den Möglichkeiten betrachten.

Und den OpenPGP Key erstelle ich immer selbst, weil ich für A und S gerne separate Subkeys erzeuge. Gerade wenn man bei Git viel signiert und der Signaturschlüssel mal kompromittiert sein sollte, braucht man dann nur den austauschen. Beispielsweise.