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

[Spike S.]

> ignore private-dev
https://github.com/netblue30/firejail/issues?q=nitrokey

Das allein reichte nicht. Anhand diesen Ansatzes habe ich mir auch mal /run/ angesehen und dort den Ordner pcscd gesehen. Daraufhin whitelist /run/pcscd in die keepassxc.local aufgenommen und es funktioniert nun (zusammen mit ignore private-dev). Ich gehe stark davon aus, dass man dies für alle physischen Keys benötigen wird, um die mit KeepassXC verwenden zu können.

Noch ein Hinweis zu dem Thema: Damit man so einen physischen Key auch auf Webseiten im Firefox nutzen kann (https://webauthn.io), muss in die firefox.local noch mindestens ignore nouf2 rein. Damit wurde ich beim Test zumindest nach dem PIN gefragt, erzählte dann aber was von zu viele Fehlversuche (da stimmt was nicht...). Ohne diesen ignore reagierte gar nix beim "Register". Mit einem ignore private-dev dazu startete FF nicht mehr bei mir bzw. brauchte recht lang zum Start.

Das Problem könnte also auf deiner Seite liegen.

Das ist gut möglich, davon gehe ich auch häufig zu erst aus. Aber in Ermangelung an Wissen, muss man dann doch mal nachfragen

Ja, du hast völlig recht, genug Starthilfe an der Stelle. Ich danke dir vielmals dafür.

Und vor allem aber auch vielen Dank für die Bündelung deines Wissens und deiner Erfahrung in dieser Anleitung. Das hat (mir) echt Spaß gemacht, ich hab noch einiges dazu gelernt und habe jetzt mehr Vertrauen in "mein" Betriebssystem, da ich mehr von den ganzen Zahnrädern im Hintergrund weiß. Zudem läuft es viel flotter auf der selben Hardware und ist um Welten sicherer als vorher.

 

[agon]

Arch Linux [Update]

• firejail
  • More infos
• TODOs
  • New: Restrict unprivileged user namespaces, but selectively allow for some apps (e.g. Steam) with AppArmor's unprivileged_userns_restriction
    -> Similar to firejails restrict-namespaces
    Note: Do not restrict namespaces for e.g. Firefox or Steam. This will lower the security.
• Virtualization
  • New: "Do not dynamically change qcow2 file ownership at runtime"
  • Change: "Enable socket (for QEMU)" instead of the libvirtd.service
  • New: "Enable networking (virbr0)"

---

Extra – FYI: Boot Loader infos (UKI w/ Secure Boot & TPM2)
> https://uapi-group.org/specifications/specs/unified_kernel_image/#uki-tpm-pcr-measurements

doas bootctl
> ...
Current Boot Loader:
      Product: n/a
     Features: ✗ ...
               ✓ Boot loader sets ESP information
         Stub: systemd-stub 254.5-1-arch
     Features: ✓ Stub sets ESP information
               ✓ Picks up credentials from boot partition
               ✓ Picks up system extension images from boot partition
               ✓ Measures kernel+command line+sysexts
               ✓ Support for passing random seed to OS
               ✓ Pick up .cmdline from addons
               ✓ Pick up .cmdline from SMBIOS Type 11
          ESP: /dev/disk/by-partuuid/<UUID>
         File: └─EFI/LINUX/ARCHLINUX-ZEN.EFI

Random Seed:
 System Token: set
       Exists: yes
...

 

[Deinorius]

Im Setup Guide 2.9 ist mir gerade zufällig aufgefallen, dass du 550 MiB angegeben hast. Die 550-Empfehlung ist mit MB gemeint, also eigentlich 512 MiB (bzw. genau 524).

 

[Spike S.]

Eine Frage zum Fall eines BIOS Updates. Wenn der Hersteller

Update AMD 5000/3000 Series CPU fTPM version, please back up Bitlocker recovery key before updating this version BIOS.

schreibt, muss man sich bei dieser Umsetzung hier Gedanken machen bzgl. Verschlüsselung bzw. UEFI Keys?
Die Verschlüsselung läuft doch ohne TPM, nur mit Passwort, wenn ich das richtig bemerkt habe, oder?
Aber mit den eigenen UEFI Keys für das Secure Boot kenne ich mich nicht aus. Bleiben die generell erhalten bei einem BIOS Update oder muss man die danach neu installieren? Hatte mich bisher nie damit befasst...

 

[agon]

tl;dr Einfach das EFI-Update durchführen. Windows benutzt TPM auch für andere Dinge.

"please back up Bitlocker recovery key before updating this version BIOS"

Zu der Warnung – ein mögliches Bsp.:
https://learn.microsoft.com/en-us/w...6-a640-4134-b742-eaf0ed2663ff#troubleshooting
"If PCR validation profile shows PCR 7, 11 (Uses Secure Boot for integrity validation), the system is configured correctly."
Aber: "If PCR validation profile doesn't show that BitLocker uses Secure Boot for integrity validation (for example, PCR validation profile says PCR 0, 2, 4, 11), this indicates that BitLocker cannot use PCR [7] […]"

-> PCR0 kann nämlich bei einem EFI-Update geändert werden. Das wäre dann ein Problem – ein Grund zur Meldung.

Die Verschlüsselung läuft doch ohne TPM, nur mit Passwort, wenn ich das richtig bemerkt habe, oder?

Genau. Man kann aber TPM2 für eine (automatische) Entschlüsselung (mit "PIN") benutzen.
Siehe: Systemd-cryptenroll#Trusted_Platform_Module & TPM#Data-at-rest_encryption_with_LUKS

Bleiben die [SB-Keys] generell erhalten bei einem BIOS Update oder muss man die danach neu installieren?

Also bei mir bleiben die erhalten. Wäre ja sonst eine Sicherheitslücke.

Es sind übrigens PCR 11 (UKI) & 15 (systemd-cryptsetup) relevant.
Siehe: Journal & https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/

---

Poll: Which Nvidia driver are you using?
Participants: 46

• nvidia: 2 4,3%
• nvidia-lts: 0 0,0%
• nvidia-dkms: 2 4,3%
• nvidia-open: 0 0,0%
• nvidia-open-dkms: 0 0,0%
• The GPU is no longer officially supported by Nvidia: 1 2,2%
• None, I use AMDGPU: 39 84,8%
• None, I use Intel graphics: 2 4,3%

 

[agon]

Arch Linux [Update]

New:

• "Steam" > "Controller settings"
  The DualSense Controller (PS5) works great in Steam (w/ adaptive trigger & haptic feedback).
• "Reverse path filtering (loose -> strict)"
• "Virtualization" > "Enable Secure Boot" for the VM
• "Windows 11 – Minimal Setup"
• And a bit more

Removed:

• "Delete all files in ~/cache/ that were last modified >30 days ago:"
  paru could not upgrade AUR packages. So just delete ~/.cache/.
• "OPT: Disable certain Linux mitigations"
• "TMP – OPT: Disable CONFIG_USER_NS_UNPRIVILEGED"

 

[D.S.i.u.S.]

Muss man vor ArchInstall die Zeit im UEFI ändern? Von unserer aktuellen Lokalzeit in Deutschland im Winter 1h und im Sommer 2h abziehen?

 

[agon]

Es wird kein archinstall im Guide ausgeführt.
Bzgl. Zeit > siehe "4.3 Time".

 

[D.S.i.u.S.]

Ich habe die 94 Seiten "überflogen". Als "How-To" kann man es nicht bezeichnen. Es sieht wie eine Wissensdatenbank mit Verweisen auf wiki aus. Viel zu viele Optionen oder Alternativen.

Am besten wäre sowas wie Arch-Build-Planner-Seite(z.B. mit Filter wie auf gh.de). Man wählt aus, was man hat oder braucht und dann wird die passende Anleitung oder Script angezeigt. z.B. Filter: Secure Boot, verschlüsselt, Nvidia-DKMS, Zen-Kernel, LAN-Verbindung usw.

 

[agon]

Als "How-To" kann man es nicht bezeichnen.

Ja, war am Anfang ein How-To. Nun ist es eher ein "Setup Guide".

Es sieht wie eine Wissensdatenbank mit Verweisen auf wiki aus.

Warum die Wiki-Einträge dabei sind, habe ich hier irgendwo geschrieben.
Sie dienen auch zur schnellen Überprüfung der Richtigkeit & Aktualität des Guides.
Es gibt auch relativ wenige Wiki-Einträge, die man lesen sollte (Tag: "READ").

Viel zu viele Optionen oder Alternativen.

Wo genau? Bspw. sind manche Nvidia-Pakete Kernel-abhängig, was dann wieder eigene Präferenz ist.
Und so viele ALTernativen gibt es gar nicht. Sie sind auch eher als Fallback zu betrachten.

Am besten wäre sowas wie Arch-Build-Planner-Seite

Du meinst so etwas wie bei archinstall oder EndeavourOS?
In den Überschriften der Abschnitte steht ja mitunter da, für was der Abschnitt gedacht ist (Tag: "for").
Der Guide ist aber auch fast ein halbes Skript.

z.B. Filter: Secure Boot, verschlüsselt, Nvidia-DKMS, Zen-Kernel, LAN-Verbindung usw.

• Secure Boot: ist in einem separatem Kapitel (5). Kann man also einfach überspringen.
• verschlüsselt: "This guide is modular. For example, if the "Ideal Secure Boot Setup" is not desirable, skip certain steps and rename /dev/mapper/root to /dev/nvme0n1p2 throughout this document."
• Nvidia-DKMS: Geschmackssache. Ich habe den Abschnitt etwas überarbeitet. Bspw. ist libva-nvidia-driver kein AUR-Paket mehr.
• Zen-Kernel: ist die Empfehlung. Andere Optionen stehen aber auch zur Auswahl.
• LAN-Verbindung: Habe dazu nichts geschrieben.

 

[agon]

Poll: Design the guide to be more script-like?​

Result:

• vim will be almost no longer needed.
• Faster setup
• Easier implementation as an installation script/program.

Vote:

• Yes: Like this post,
• No: Let me know in a post why not.

 

[Spike S.]

Bei der Installation hatte ich oft das Gefühl, ein Skript könnte das besser übernehmen. Da war ja wenig individuelles dabei, also kaum was hardwarespezifisches. Darum kümmern sich die einzelnen Programme ja schon selbst in der Regel.
Aber mir kam dann auch die Frage, wie lange man an so einem Skript feilen muss, damit es sich robust verhält und bei Problemen nicht gleich alles in einem gigantischen Feuerball in Rauch aufgeht 🤔

 

[andy_m4]

Bei der Installation hatte ich oft das Gefühl, ein Skript könnte das besser übernehmen. Da war ja wenig individuelles dabei, also kaum was hardwarespezifisches.

Naja. Bei einer solchen Anleitung geht es ja weniger darum die Schritte einfach nur stumpf auszuführen. Es geht ja auch damit zu lernen, was gemacht wird und z.B. bestimmte Dinge wegzulassen oder in abgewandelter Form auszuführen, um individuellen Anforderungen genüge zu tun.

Wenns tatsächlich nur darum geht, bestimmte (insbesondere wiederkehrende) Dinge zu automatisieren, dann ist man mit einem Skript sicher besser dran.

 

[agon]

Beispiele (bis Abschnitt 8), bei denen ich vim ersetzen würde.
=> Ersetzen durch echo, sed, etc.
tl;dr: Es werden oft neue Dateien erstellt & unkommentiert.
vim bleibt bei Operationen, bei denen der User selber entscheiden soll bzw. muss (bspw. die Locales).

    vim /etc/ssh/sshd_config
    > PermitRootLogin yes
    vim /etc/fstab
    > Append:
    # /swap/swapfile
    /swap/swapfile    none    swap    defaults    0 0
    vim /etc/sysctl.d/99-swappiness.conf
    > vm.swappiness = 10
    vim /etc/cmdline.d/root.conf
    >
    # Btrfs: GPT partition automount
    rootflags=subvol=@
    # Hide OEM logo & Reduce boot messages
    bgrt_disable quiet loglevel=4
    vim /etc/cmdline.d/performance.conf
    > …
    vim /etc/doas.conf
    >
    permit :wheel
    permit persist :wheel
 
    vim /etc/pam.d/su
    vim /etc/pam.d/su-l
    > Uncomment:
      auth required pam_wheel.so use_uid
    vim /etc/pacman.conf
    > Uncomment:
      Color
      ...
      ParallelDownloads = 5
    …
    [multilib]
    Include = /etc/pacman.d/mirrorlist
    vim /etc/systemd/journald.conf
    > Uncomment:
      SystemMaxUse=200M
    vim /etc/makepkg.conf
    >
    cpu_threads := $ nproc
    > Uncomment:
      MAKEFLAGS="-j<cpu_threads>"
    > COMPRESSZST=(zstd -c -z -q --threads=0 -)
    vim /etc/sddm.conf.d/rootless-x11.conf
    >
    [General]
    DisplayServer=x11-user
    vim /etc/sddm.conf.d/virtualkbd.conf
    >
    [General]
    InputMethod=qtvirtualkeyboard

Aber mir kam dann auch die Frage, wie lange man an so einem Skript feilen muss, damit es sich robust verhält und bei Problemen nicht gleich alles in einem gigantischen Feuerball in Rauch aufgeht

https://doc.rust-lang.org/std/process/index.html
Mit Rust geht ja einiges. Aber auch alles (vom Guide)?
Auf jeden Fall ist das ein großer Aufwand.

---

Das Problem mit den ODT-Dateien ist, dass man daran relativ schlecht zusammen arbeiten kann. Es ist aber für mich relativ komfortabel mit LibreOffice zu arbeiten.

Es gibt zwar LaTeX, welches das "Problem" lösen würde. Es wäre aber wahrscheinlich sehr umständlich das zu porten. Habe auch noch keine komfortable "Writing environment" gefunden.

Und dann gibt es noch Rust, bei welchem man abgesehen von einem Arch-Installer, auch eine gewisse Dokumentation hätte.
https://doc.rust-lang.org/stable/book/ch14-02-publishing-to-crates-io.html
https://doc.rust-lang.org/rustdoc/what-is-rustdoc.html

 

[Spike S.]

Naja. Bei einer solchen Anleitung geht es ja weniger darum die Schritte einfach nur stumpf auszuführen. Es geht ja auch damit zu lernen, was gemacht wird und z.B. bestimmte Dinge wegzulassen oder in abgewandelter Form auszuführen, um individuellen Anforderungen genüge zu tun.

Wenns tatsächlich nur darum geht, bestimmte (insbesondere wiederkehrende) Dinge zu automatisieren, dann ist man mit einem Skript sicher besser dran.

Ja okay, da hast du schon recht. Dann war das mein Gefühl, weil ich das allermeiste schon kenne und nur sehr wenig die Hintergründe querlesen musste.
Bei einem Skript, kann man ja an kritischen Stellen oder bei denen es um unterschiedliche Philosophien geht, Abfragen einbauen und einen Default vorschlagen.

@agon
Kann man mit RUST auch skripten? Habe mich bisher damit nicht befasst, mein Wissen beschränkt sich im Wesentlichen auf "das gibt es". Hab es aber bisher als ausgewachsene Sprache, á la C++ verbucht.

Und wenn mehrere darauf arbeiten sollen, wäre da nicht eher Github/Gitlab/Codeberg/... angebracht? Zumindest beim Skript, ändert aber nix an dem ODT Problem...außer man switcht auf Markdown, also blanker Text, oder so.

 

[agon]

Kann man mit RUST auch skripten?

Ja. Also man kann bspw. sh -c <…> ausführen,
mit bspw. cat security_notice.txt: https://play.rust-lang.org/?version...on=2021&gist=c09215edef28f78c5b74c534e3a32bda

Habe gerade den Befehl pacman -Qs vim bei mir getestet. Funktioniert in RustRover (ohne firejail).
doas funktioniert auch.

wäre da nicht eher Github/Gitlab/Codeberg/... angebracht?

Das wäre der Plan.

außer man switcht auf Markdown

Markdown wird ja in Rust nativ unterstützt.

 

[Beelzebub23]

Erstmal vorab, vielen Dank für diesen Guide / HowTo / wie auch immer man es nennen mag. Diese große Wissenssammlung und die Modularität haben mich dazu gebracht, Arch auszuprobieren und ich bin sehr zufrieden. Danke!

Für meine erste Installation fand ich die aktuelle Form sehr hilfreich, da ich es ohne ssh von einem zweiten Rechner installiert hab. Ich hatte nur das Zielsystem und das pdf auf einem Tablet offen. Kein Copy'n'Paste der Befehle, keine Skriptausführung, nichts in der Richtung. Alles handgeschrieben und dabei versucht zu verstehen.
Dabei passieren natürlich Fehler (den führenden Punkt bei snapshots vergessen ) aber am Ende läuft das System und ich versuche alles darauf zu machen. Dabei kommen dann nach und nach Funktionen zu Tage, die man dann per pacman oder paru nachinstalliert.

Ich wüsste tatsächlich nicht, wie ich eine Erstinstallation mit Skripten / Rust durchgeführt hätte, da ich diese nicht auf das Zielsystem bekommen hätte.

Insofern finde ich, für mich, die aktuelle Variante sehr gut.

 

[Deinorius]

Ich wäre auch für die bisherige Ausführung, es empfiehlt sich zum Lernen und Nachschlagen.
Natürlich bietet es sich an, mehr Befehle von vim auf echo und sed zu wechseln, wo es Sinn macht.
Und wenn es darum geht, das als ausführbares Skript z.B. auf Github zu stellen, die gibt es im Grunde ja schon. (Zugegeben, es ist nicht alles drin, z.B. Secure Boot, und ich bin gerade zu faul, die aktuellsten Änderungen einzupflegen...)

Als Zusatz für dein Guide folgender Hinweis: Unter 4.8.1 erwähnst du, dass hibernation mit RAM > swap funktionieren kann.
Aus persönlicher Erfahrung kann ich sagen, dass hibernation mit 8 GB RAM und 7,5 GB swap manchmal nicht wollte. Mit 16 GB RAM und gleich großer swap Datei ich im Grunde nie Probleme mit hibernation habe, so lange ich den RAM nicht überfülle. Mit 8 GB RAM wird im Betrieb der swap gefüllt und das führt zu Problemen mit hibernation.

Ich weiß nicht, ob Interesse daran besteht, aber ich behelfe mir manchmal, indem ich den RAM freiräume.
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
Habe es in .zshrc auch als alias vereinfacht.
alias freeram='sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"' # Free RAM cache

 

[agon]

@Beelzebub23 Danke für dein Feedback.

Kein Copy'n'Paste der Befehle

Ich denke mal dann aber ohne Secure Boot?

Dabei kommen dann nach und nach Funktionen zu Tage, die man dann per pacman oder paru nachinstalliert.

Du kannst übrigens jene Pakete nennen, wenn du sie für empfehlenswert hältst.

Ich wüsste tatsächlich nicht, wie ich eine Erstinstallation mit Skripten / Rust durchgeführt hätte, da ich diese nicht auf das Zielsystem bekommen hätte.

Bspw. mit git. Würde man dann in der Anleitung sehen.

---

@Deinorius

Natürlich bietet es sich an, mehr Befehle von vim auf echo und sed zu wechseln, wo es Sinn macht.

Man kann leider kein doas echo ausführen. Geht nur über Umwege wie sh -c. Für diejenigen, welche das bspw. abtippen würden, wäre das dann ein höherer Aufwand.
sed kann gerne mal kryptisch aussehen. Vielleicht doch eher etwas für ein Skript.

Ein aktuelles Skript wäre eben auch für eine Test-Installation ganz hilfreich. Bei Arch ändert sich ja auch einiges wie die Namen der Pakete. Oder ich lasse es einfach andere herausfinden.

Unter 4.8.1 erwähnst du, dass hibernation mit RAM > swap funktionieren kann.

New: "If the swap size is smaller than the RAM size and the RAM is not fully utilized, you still have a chance of hibernating successfully."
War eher für den Fall gedacht, wenn man mehr als 32 GiB hat. 32 GiB von 2 TB ist denke ich mal vertretbar.

Apropos Hibernation. Changelog von systemd v255:
"Hibernation into swap files backed by btrfs are now supported. (Previously this was supported only for other file systems.)"
Und der Kernel Parameter resume= soll auch nicht mehr benötigt werden.

 

[Beelzebub23]

@agon Da hast du mich

Ich denke mal dann aber ohne Secure Boot?

Völlig richtig. Kein Secure Boot und kein LUKS. Da meine Backups eh hier gerade noch unverschlüsselt auf ner externen Platte und nem (openmediavault)NAS landen, hab ich davon erstmal abgesehen. Sobald ich mich in die Verschlüsselung und die Möglichkeiten ein NAS mit Verschlüsselung ohne Benutzereingaben zu starten eingelesen hab, geh ich auch wohl mal daran...

Deshalb mag ich den Guide auch so wie er ist. Die Modularität sagt mir zu. Ich hab mich auch noch nicht an AppArmor und FireJail gesetzt.

Du kannst übrigens jene Pakete nennen, wenn du sie für empfehlenswert hältst.

Da ist aktuell nichts bei, was ich als allgemeine Empfehlung sehen würde. Ich beschäftige mich gerade noch mit RDP, um auf einem Laptop zu arbeiten, ohne Bildschirme und Tastatur umbauen zu müssen. Das ist aber noch etwas hakelig und deshalb hab ich tatsächlich noch als DualBoot ein Windows hier.
Auch das setzen eines Bilds in ein PDF ohne dabei das PDF zu zerschießen seh ich nicht so als alltägliche Aufgabe.

Bspw. mit git. Würde man dann in der Anleitung sehen.

Ah, das ist natürlich wirklich eine interessante Möglichkeit. Wobei da vielleicht auch für manche Anwender eine Hürde entstehen würde, dies zu verstehen und nachzuvollziehen.


Eine Sache ist mir aber doch noch aufgefallen.
MangoHud / Kapitel 13.6. Da sollen in der Config so einige Sachen einkommentiert werden, wo du auch im Kapitel 13.6.1.1 VISUAL in den Zeilen überall das Kommentarzeichen entfernt hast.
In Kapitel 13.6.1.2 INTERACTION sind aber noch die Kommentarzeichen vor dem toggle_hud und toggle_logging vorhanden. Nach meinem Verständnis der Anleitung müssten die doch auch weg, oder?