Das technische Komitee, das endgültige Entscheidungen zu umstrittenen technischen Fragen im Debian-Projekt trifft, hat die Änderung des Pakets mit systemd genehmigt, die das Verhalten im Zusammenhang mit dem Verzeichnis /var/lock ändert. Der Systemmanager systemd hat ab Version 258 die Möglichkeit, in das Verzeichnis /var/lock zu schreiben, nur auf Benutzer mit root-Rechten beschränkt, während das technische Komitee von Debian das alte Verhalten genehmigt hat, das das Schreiben in /var/lock für alle Benutzer erlaubt.
Die Regeln des Debian-Projekts schreiben vor, dass das ursprüngliche Verhalten von Anwendungen (Einstellungen, die in der upstream-Version eingestellt sind) bei der Paketbildung beibehalten wird. Für spezifische Änderungen in Debian-Paketen, die die Projektregeln umgehen, ist die Genehmigung des technischen Komitees erforderlich.
Im Fall von systemd unterstützte der Ausschuss den Vorschlag, die Änderung, die die Zugriffsrechte auf /var/lock verändert, um die Sicherheit zu erhöhen, abzulehnen, da die Möglichkeit des öffentlichen Schreibens in das Verzeichnis /var/lock in der Spezifikation FHS (Filesystem Hierarchy Standard) erwähnt wird und für den Betrieb bestimmter bestehender Programme erforderlich ist. Beispielsweise verwenden Anwendungen für serielle Ports wie uucp, minicom, mgetty+sendfax und hylafax das Verzeichnis /var/lock, um den Zugriff auf die Geräte /dev/ttyS* durch das Erstellen von Lockfiles zu trennen.
Die Notwendigkeit, den Zugriff auf das Verzeichnis /var/lock einzuschränken, wird von den Entwicklern von systemd als Schutz vor DoS-Angriffen erklärt. Das Verzeichnis /var/lock ist ein symbolischer Link zum Verzeichnis /run/lock. Der Abschnitt mit dem Verzeichnis /run wird normalerweise separat über tmpfs gemountet, und die Möglichkeit des unkontrollierten Schreibens darin kann genutzt werden, um den Abschnitt zu überlaufen und die Erstellung neuer Dateien in der Hierarchie /run zu blockieren.
Um Angriffe mit unbeschränktem Zugriff zu verhindern, wurde in Debian früher ein Patch verwendet, der /run/lock in einem separaten kleinen tmpfs-Volume mountet. Im letzten Jahr wurde dieser Patch durch das Unit run-lock.mount ersetzt, und diesen Sommer wurde dieses Unit entfernt, wodurch /run/lock im Verzeichnis /run gelandet ist. In den Kommentaren zu dieser Entscheidung empfahl der ehemalige Maintainer von systemd, die vorgenommene Änderung nicht zu vergessen und zum separaten Mounten von /run/lock zurückzukehren. Langfristig sollten alle Anwendungen, die auf /run/lock angewiesen sind, auf Sperren mit dem Mechanismus flock umgestellt werden.
Quelle: opennet.ru
