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

[Deinorius]

Hab ich das jetzt richtig verstanden, dass der Code 8304 die aktualisierte Variante für dm-crypt und spezifisch für x86_64 ist? Ich bin etwas verwirrt, weil du im Dokument in der Tabelle noch 8309 schreibst, während die Ausführung mit 8304 erfolgt.
Noch zu deinem Vorhaben, eine config für mpv zu erstellen. Welche Vorteile erwartest du dir davon genau? Der Standard funktioniert ja generell ganz gut und die aktuellste Version kommt mit sinnvollen Updates daher.

 

[cbtestarossa]

Ein paar Dinge die mir so nebenbei einfallen.
Warum härten die Jungs nicht gleich den Kernel und bieten den gleich bei der Installation mit an?

DNS könnte man DNS-Crypt(Proxy) verwenden. Läuft aber glaub bei Wifi-Hotspots nicht.

Unter einer Personal Firewall verstehe ich am Client-PC aber was anderes als den ganzen Mist den es da gibt.
Und zwar eine mit GUI die selbstständig meldet wenn sich was rausmelden will und dann den User entscheiden lässt was zu tun ist. Temporär und permanent.
Die Entscheidung ist oft gar nicht so einfach aber zumindest bei Anwendungsprogrammen ist das ersichtlich.

AntivirGuard mit GUI wahrscheinlich auch Fehlanzeige.

Browser Config. Jup da könnte Mozilla sicher auch einiges gleich machen.
Leider werden dann gewisse Webseiten etwas herumzicken.

AppAmor usw. ist sicher nicht schlecht aber viel zu umständlich.
Sandbox Verfahren könnte auch gleich automatisch erfolgen.
Zumindest bei bekannter Software,

Ist aber eh unter Windows auch alles das selbe.
Alles was nicht vollautomatisch läuft ist halt für Otto Normalo unbrauchbar.

 

[andy_m4]

Warum härten die Jungs nicht gleich den Kernel und bieten den gleich bei der Installation mit an?

Welche Jungs?

AntivirGuard mit GUI wahrscheinlich auch Fehlanzeige.

Was soll den dieser angedachte AntivirGuard machen?

AppAmor usw. ist sicher nicht schlecht aber viel zu umständlich.

Im besten Fall hat man vorgefertigte Profile die man dann einfach nimmt.

Alles was nicht vollautomatisch läuft ist halt für Otto Normalo unbrauchbar.

Ähm. Es geht hier in dem Thread um ein Arch Linux (ist ansich schon keine Lieschen-Müller-Distro) was dann auch noch "handoptimiert" wird. Das ist keine Anleitung die sich an nen Otto-Normal-Verbraucher richtet.

 

[cbtestarossa]

Jup handoptimiert. Genau das meinte ich mit Jungs und automatisch.

 

[agon]

@Deinorius
Die "8309" in der Übersichts-Tabelle hatte ich vergessen zu ändern. Ist nun auch "8304" 👍.

---

@cbtestarossa

Warum härten die Jungs nicht gleich den Kernel und bieten den gleich bei der Installation mit an?

Es gibt doch linux-hardened. Ob dann aber alles immer noch funktioniert, ist die andere Sache.
Siehe: https://wiki.archlinux.org/title/Kernel#Officially_supported_kernels
-> Die RayTracing kernels linux-rt & linux-rt-lts sind übrigens nun auch offiziell.

DNS könnte man DNS-Crypt(Proxy) verwenden.

Bei meinem Desktop-PC übernimmt das der Router (DNS over TLS & DNSSEC). In unsicheren Netzwerken sollte VPN aber besseren "Schutz" bieten. Das Verhältnis zwischen Nutzen und (Aufwand & mögliche Probleme) ist mMn relativ niedrig.

AppAmor usw. ist sicher nicht schlecht aber viel zu umständlich.

AppArmor ist bspw. auch fester Bestandteil von openSUSE & Ubuntu.
Man kann ja auch Firejail nur für ausgewählte Programme benutzen. Flatpak-Programme sind bspw. zu einem gewissen Grad schon gesandboxt.

 

[cbtestarossa]

Bei meinem Desktop-PC übernimmt das der Router (DNS over TLS & DNSSEC). In unsicheren Netzwerken sollte VPN aber besseren "Schutz" bieten. Das Verhältnis zwischen Nutzen und (Aufwand & mögliche Probleme) ist mMn relativ niedrig.

Nur dass DNScrypt auch verschlüsselt und DoT und DNSsec unterstützt.
Denk aber dass kein Billigrouter das schon unterstützt.

Zum Rest:
Wenn das OS schon mal alles isolieren würde wäre das schon mal ein großer Schritt nach vorne.
Es gibt ja eh schon Konzepte dazu.
Eines ist sogar so konzipiert dass selbst der Kernel isoliert und im Userland lief.
Waren denk alles Microkernel Lösungen.

 

[andy_m4]

Wenn das OS schon mal alles isolieren würde wäre das schon mal ein großer Schritt nach vorne.

QubesOS.

Eines ist sogar so konzipiert dass selbst der Kernel isoliert und im Userland lief.

Völlig ohne privilegierte Schicht wird man wohl nicht auskommen.

Waren denk alles Microkernel Lösungen.

Auch bei einem Mikrokernel läuft nicht alles im Userland. Allerdings vieles und die Idee dahinter ist den Teil, der privilegiert laufen muss möglichst klein zu halten. Daher auch das Mikro im Namen.

 

[cbtestarossa]

Ja, QubesOS ist eines davon.
Und auch klar dass irgend etwas mit höchsten Rechten laufen muss um alles zu verwalten.

 

[Beelzebot]

@agon Wieso verwendest du fast überall ein Semikolon bei den Konsolenbefehlen?
Gerade bei den Subvolumes ist das irritierend -> @;
Ansonsten, spitzenmäßige Anleitung!

 

[agon]

Wieso verwendest du fast überall ein Semikolon bei den Konsolenbefehlen?

Damit man den nächsten Befehl gleich mit absenden kann. In LibreWriter ist das so:

• Markiert man zusammenhängende Zeilen wie bei den Subvolumes, also
  Spoiler: folgende Zeilen

  btrfs su cr /mnt/@; # /
  btrfs su cr /mnt/@Home; # /home
  btrfs su cr /mnt/@snapshots; # /.snapshots
  btrfs su cr /mnt/@srv; # /srv
  btrfs su cr /mnt/@swap; # /swap
  btrfs su cr /mnt/@var_abs; # /var/abs
  btrfs su cr /mnt/@var_cache_pacmanPkg; # /var/cache/pacman/pkg
  btrfs su cr /mnt/@var_lib_containers; # /var/lib/containers
  btrfs su cr /mnt/@var_lib_libvirtImages; # /var/lib/libvirt/images
  btrfs su cr /mnt/@var_log; # /var/log
  btrfs su cr /mnt/@var_tmp; # /var/tmp
  , wird das auch so beim Pasten übernommen -> ENTER. Semikolon bräuchte man hier nicht
• Markiert man keine zusammenhängenden Zeilen, also mit Strg gedrückt, dann werden die beim Pasten nebeneinander (und nicht übereinander) eingefügt.
  Um das also einheitlicher zu gestalten, findet man oft nach einem Befehl ein "; ".
• In der Tabelle "Styles & Meaning" ist das optionale "; " nun auch dabei. Die ";" bei den Subvolumes sind nun nicht mehr fettgedruckt.

---

Arch Linux [Update]:

• GPT partition automounting is now working, by setting the default btrfs subvolume @.
  Therefore, the following kernel parameters are no longer required:
  rd.luks.name=<blkid -o value -s UUID /dev/nvme0n1p2>=root root=/dev/mapper/root rootflags=subvol=@
  Q: What do you think about "GPT partition automounting"?
• Update: /etc/mkinitcpio.conf -> HOOKS
• Update: New fonts: Adobe Source Sans Pro (higher quality than Noto), Fira Code (Mono w/ programming ligatures)

 

[Snakeeater]

Ich hab den Thread nur überflogen und finde eine Arch Installationsanleitung überaus löblich. Auch scheint mir die Komponentenauswahl sehr gut durchdacht, auch wenn ich marginale andere Präferenzen hätte (fish statt zsh).

Aber ein großer Knackpunkt scheint mir:
Sehe ich richtig, dass Komponenten noch zu Beginn des Jahres großartig abgeändert wurden? D.h. es besteht kein Langzeittest des hier empfohlenen Systems und alle ihrer Komponenten?
Finde ich etwas fahrlässig und würde mich davon abschrecken so ein System tatsächlich für den Alltagsbetrieb zu nutzen.

 

[Deinorius]

Kannst du spezifizieren, was du genau meinst?

 

[agon]

@Snakeeater
Zu Zsh habe ich passende Pakete zum Installieren & eine Konfigurationsdatei, womit ich ganz gut fahre (falls du dir die noch nicht angeschaut haben solltest). Der Guide ist modular und man kann natürlich viele Dinge auch anders lösen.

Sehe ich richtig, dass Komponenten noch zu Beginn des Jahres großartig abgeändert wurden? D.h. es besteht kein Langzeittest des hier empfohlenen Systems und alle ihrer Komponenten?

• Weitreichende Änderungen bzgl. der Installation waren bspw. die Umstellungen auf btrfs & UKI (März 2022)
• Die vielen anderen vorgenommenen Änderungen & Ergänzungen sind meist leicht übernehmbar
• Auf meinem Notebook läuft das komplette Programm seit dem 11.03.2022 (ohne GPT Automounting) ohne Probleme. Ich benutze es aber auch relativ selten.
• Wenn ich Änderungen an der Installation vornehme, dann teste ich die oft bis SDDM (also alles ab "btrfs snapshots" teste ich üblicherweise nicht).
• Ich vermeide große Änderungen bzgl. der Installation. Eine mögliche zukünftige Änderung wäre wohl das Thema TPM2, welches wie auch Secure Boot optional werden würde.
• Die meisten "Guide-Versionen", welche ich veröffentlicht habe, sollten natürlich immer noch funktionieren. Sonst hätte hier jemand auf Fehler hingewiesen
• Bei den meisten Problemen (verursacht durch ein Systemupgrade), kann man halt auch sein System "zurücksetzen" (aka. "Restoring / to its previous snapshot"). Das ist einer der Gründe, welches das System stabil machen sollte.

Spoiler: Fun-facts

• Ich benutze Arch Linux seit dem 14.06.2021 auf meinem Desktop-PC.
• Davor war Manjaro für ~1 Jahr installiert bis sich Manjaro durch ein Update sich selbst verabschiedet hatte. Dann wurde halt Arch installiert – das war ein Anlass.
• Davor hatte ich mit Linux nichts am Hut. Mit Windows 10 hatte ich auch noch nie großartige Stabilitätsprobleme. Die ersten Versionen des Setup Guides wurden mit MS Office geschrieben.

 

[Snakeeater]

Huihuiui, erstmal danke für deine Offenheit und Ehrlichkeit. Mit einem Jahr Linux Erfahrung ein Arch Installationsguide zu schreiben ist schon heftig. Ich nutze Linux seit über 5 Jahren und würde mich sowas nicht zutrauen.

Dann wäre da noch der Fakt, dass du die eigentliche Installation nicht regelmäßig nutzt. Für mich ist das leider ein K.O. Kriterium. Mich würde auch mal interessieren warum du es nicht nutzt? Daily driver Windows/ne andere Distro?

 

[agon]

Dann wäre da noch der Fakt, dass du die eigentliche Installation nicht regelmäßig nutzt.

Ich möchte halt nicht jedes mal Arch Linux nach jeder kleinen Änderung neu installieren.
Ich benutze doch Arch Linux auf meinem Hauptrechner. Bloß eben noch ohne Btrfs & UKI.
Mein Notebook machte wie geschrieben bis jetzt keine Probleme mit Btrfs & UKI.
Du kannst ja nach weiteren Erfahrungsberichten zu Btrfs & UKI suchen. Ich kann dir nur schreiben, dass Btrfs & UKI gerade populär sind (siehe bspw. hier).

Mich würde auch mal interessieren warum du es nicht nutzt? Daily driver Windows/ne andere Distro?

Ich schrieb doch:

Ich benutze Arch Linux erst seit dem 14.06.2021 (auf meinem Desktop-PC).

Ich habe nur einen Desktop-PC.

 

[Snakeeater]

Oh dann habe ich dich falsch verstanden. Habe es so aufgefasst, dass du es nur auf dem Laptop installiert hast und dort kaum nutzt.

Mea culpa!

 

[agon]

Arch Linux [Update]

• Chapter restructure starting from chapter SDDM
  • New: "Software specific". Some topics were moved there.
  • Chapter "Next steps" has been separated.
  • New: "ROCm & HIP" (in repo "Community-Testing")
• Update & Fix: "Restoring / (subvolume @) to its previous snapshot"
• Update: Config files

 

[agon]

Arch Linux [Update]

• Update: Easier swapfile setup (since linux 6.1) FINALLY!

---

Info: Hibernation funktioniert (nur bei mir?) nicht mit Virt-Manager (VM freezt immer beim "Resumen").

Nebenbei bekam ich nach dem Wechsel der GPU in den VMs auch kein Bild mehr. Kann man alles sicherlich fixen, so wichtig waren dann die VMs aber auch wieder nicht. Das Thema "PCI passthrough via OVMF" erscheint mir dann doch leider zu instabil.

 

[agon]

Arch Linux [Update]

• Remove: "GPT partition automounting"
  • Remove: btrfs subvolume set-default /mnt/@

---

Ich habe Arch Linux auf meinem Notebook installiert, um Hibernation zu testen. Ich habe dazu einfach nur einen USB-Stick (UASP, M.2 SATA) platt machen müssen.
UND ES FUNKTIONIERT. (Nur nicht mit Virt-Manager)

Danach habe ich geschaut, ob das Setzen des "Default Subvolumes" Subvolume- oder Pfad-bezogen ist. Wie befürchtet – Subvolume-bezogen.
Man müsste somit immer nach btrfs subvolume snapshot /mnt/@snapshots/<num>/snapshot /mnt/@, btrfs subvolume set-default /mnt/@ ausführen.
=> "GPT partition automounting" fliegt raus & man darf wieder mehr Kernel Parameter eingeben (Juhu!).
(Hibernation wurde nicht getestet, sollte aber funktionieren!)

Ich behaupte mal einfach, dass der Guide jetzt wieder stabil sein sollte.

 

[agon]

Arch Linux [Update]

• Update: Secure Boot
  • New: Microsoft's certificates (esp. Microsoft Corporation UEFI CA 2011 certificate)
    Dual Boot with Windows should now be possible.
  • New: Enrolling keys using sbkeysync & more…

---

Ich habe nun auch Secure Boot auf meinem Desktop-PC (ASUS-Mainboard) eingerichtet. Dabei ist mir folgendes aufgefallen:

• Es gibt zwei Secure Boot Optionen aka. "OS Type": "Windows UEFI mode" & "Other OS".
  • Ich habe dementsprechend "Other OS" genommen & habe meine eigenen Keys eingetragen.
  • Secure Boot Status in Arch ist "disabled"? Das wundert mich, denn der "Secure Boot state" im UEFI steht immer? auf "Enabled". Ein Ein/Aus-Schalter für "Secure Boot" gibt es auch nicht.
  • Im "Windows UEFI mode" konnte ich Arch nicht starten. "Vielleicht ja mit den Zertifikaten von MS?"
• https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Microsoft_Windows
  "The Microsoft Corporation UEFI CA 2011 certificate aka the Microsoft 3rd Party UEFI CA certificate should be included in the DB variable in order to use third-party binaries like UEFI drivers, option ROMs, shim, etc."
  • Habe das Zertifikat eingebunden & Secure Boot funktioniert nun im "Windows UEFI mode"!
• Die Info von ASUS zu den beiden SB-Optionen:

tl;dr:

• ASUS irritiert bei den SB-Bezeichnungen. Ich übersetze mal:
  • "OS Type" = Secure Boot
  • "Windows UEFI mode" = SB ist aktiviert, das "Microsoft Corporation UEFI CA 2011" Zertifikat ist aber erforderlich
  • "Other OS" = SB ist deaktviert
  • "Secure Boot state" sagt nichts aus, da es wahrscheinlich immer aktiviert ist
• Falls SB bei euch nicht funktionieren sollte, dann einfach mal das "Microsoft Corporation UEFI CA 2011" Zertifikat einbinden.