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
