Nicht genau. Tatsächlich ist das alte rc.d-init-System wahrscheinlich viel einfacher zu prüfen, da es in einem Shellskript geschrieben ist ( edit : mit Ausnahme des init-Daemons selbst, geschrieben in C) und viel kürzer ist. Das ‚alte‘ Init - System selbst ist nicht wirklich so viel mehr oder weniger sicher per se ( edit : obwohl es nicht mehr Code und ein dbus - Schnittstelle - mehr Raum für Fehler, etc.). systemd hat eine bessere Isolierung der Prozesse, die es verwaltet, von Anfang an, indem es in seine eigenen Gruppen eingereiht wird, aber das allein macht an sich nicht viel aus, außer robuste Etikettierungsprozesse. Es könnte mit dem folgenden Gespräch verglichen werden.
- Hier ist diese Gruppe von Arbeitern, und hier ist eine andere Gruppe. Wir haben sie in Gruppen aufgeteilt. Sie können keine Gruppen wechseln. Nur der Supervisor kann Ihre Gruppe einstellen.
- Okay. Aber hast du noch etwas gemacht?
- Nein.
- Erzwingen Sie Regeln wie "Gruppe A benötigt nur Zugriff auf diese Ressourcen, sodass ihnen nur Zugriff auf diese Ressourcen gewährt wird"?
- Nein.
- Isolieren Sie jede Gruppe vollständig von einer anderen?
- Nein.
Wie SysV init, das alte Arch Linux-Init-System (das wirklich auf SysV aufgebaut ist), systemd usw. haben Sie natürlich einige grundlegende Konfigurationen der verschiedenen Dinge (um nicht spezifisch zu sein), die automatisch verwaltet werden (egal, ob sie gestartet wurden) zu beliebiger Zeit booten xoder getötet werden, wenn Schweine plötzlich fliegen lernen). Diese Dinge (Einheiten wie systemd sie nennt), haben eine Art von Konfigurationsschnittstelle (in systemd, eine INI-like coonfiguration Datei, unterstützen systemd erzählt Verwendung von einigen Linux - Kernel - Funktionen zu machen, die die Sicherheit Ihres Systems erhöhen. Hier sind ein paar Beispiele, gezogen aus systemd.exec(5):
- Whitelist und Blacklists für Geräteknoten für diesen Prozess (
DeviceAllow,DeviceDeny) - Filsystem Namespacing (
ReadWriteDirectories,InaccessibleDirectories,PrivateTmp, etc.) - Netzwerkzugriff verweigern (einmalig
PrivateNetwork) - UID-Änderungen verweigern (
NoNewPrivileges) - Bestimmte Systemaufrufe herausfiltern (
SystemCallFilter)
All dies kann verwendet werden, um das Verhalten der Prozesse, die vom init-System erzeugt werden, weiter einzuschränken. Sie können ein gewisses Maß an Komfort von solchen Einschränkungen ableiten, die Sie für angemessen halten.
Bis jetzt habe ich keine weitverbreitete Verwendung dieser gesehen, und ich habe auch keine ernsthaften Anstrengungen bemerkt, verschiedene Dienste mit systemd so weit wie möglich zu sperren. Das heißt, ich bin nicht vertraut mit den inneren Gängen jedes Projekts usw., also nimm mein Wort mit einem Salzkorn.
Arch Linux versucht im Allgemeinen, Software aus vorgelagerten Quellen mit so wenig Modifikationen wie möglich zu verwenden. Ich verstehe, dass, anstatt unser eigenes System aufrechtzuerhalten, nur systemd gewählt wurde, da es scheinbar das de-facto Standardsystem ist (ob es de facto eine Frage der Debatte ist). Daher weniger Arbeit für die Arch Linux-Betreuer.
Eine letzte Bemerkung: Arch Linux hat niemals update-rc, chkconfig oder ähnliches verwendet. Dies sind Debianismen, Fedora / RedHat / CentOS / whateverisms usw. Ich würde vorschlagen, das aus der Frage zu streichen. systemctlist nur eine Schnittstelle für den systemdProzess, wie telinitbei SysV, daher empfehle ich auch, das zu entfernen. Arch Linux hat zwar versucht, die SysV-Grundlagen mit seinem BSD-ähnlichen Init-System zu verbergen, also lasse ich das. Am Ende so etwas wie "Warum ersetzt systemd SysV / BSD init?" sollte angemessener sein.