Komitet techniczny, który podejmuje ostateczne decyzje w sprawie kontrowersyjnych kwestii technicznych w projekcie Debian, zatwierdził wprowadzenie zmiany w pakiecie systemd, która zmienia zachowanie związane z katalogiem /var/lock. Menedżer systemu systemd od wersji 258 ograniczył możliwość zapisu do katalogu /var/lock tylko dla użytkowników z uprawnieniami root, podczas gdy komitet techniczny Debiana zatwierdził pozostawienie starego zachowania, zezwalającego na zapis w /var/lock wszystkim użytkownikom.
Zasady projektu Debian nakazują zachowanie pierwotnego zachowania aplikacji (ustawień określonych w upstream) podczas tworzenia pakietów. Aby wprowadzić do pakietów typowe dla Debiana zmiany z pominięciem zasad projektu, wymagane jest uzyskanie specjalnego pozwolenia od komitetu technicznego.
W przypadku systemd komitet poparł propozycję, aby nie stosować zmiany, która zmienia uprawnienia dostępu do /var/lock w celu zwiększenia bezpieczeństwa, ponieważ możliwość publicznego zapisu w katalogu /var/lock jest wymieniona w specyfikacji FHS (Filesystem Hierarchy Standard) i jest niezbędna do kontynuowania pracy niektórych istniejących programów. Na przykład aplikacje do obsługi portów szeregowych, takie jak uucp, minicom, mgetty+sendfax i hylafax, używają katalogu /var/lock do rozdzielania dostępu do urządzeń /dev/ttyS* poprzez tworzenie plików blokujących.
Konieczność ograniczenia dostępu do katalogu /var/lock jest wyjaśniana przez deweloperów systemd ochroną przed atakami DoS. Katalog /var/lock jest symbolicznym linkiem do katalogu /run/lock. Sekcja z katalogiem /run zazwyczaj jest montowana osobno przez tmpfs, a możliwość niekontrolowanego zapisu do niego może być wykorzystywana do przepełnienia sekcji i blokowania tworzenia nowych plików w hierarchii /run.
Aby wykluczyć takie ataki przy nieograniczonym dostępie, wcześniej w Debianie używano łatki montującej /run/lock w osobnej, niewielkiej partycji tmpfs. W zeszłym roku ta łatka została zastąpiona jednostką run-lock.mount, a tego lata jednostka została usunięta, po czym /run/lock znalazło się w partycji /run. W komentarzach do decyzji technicznego komitetu były główny opiekun systemd zalecił, aby nie zapominać o tym zauważonym zmianie i wrócić do osobnego montowania /run/lock, a w dłuższej perspektywie przekształcić wszystkie aplikacje powiązane z /run/lock na blokady za pomocą mechanizmu flock.
Źródło: opennet.ru
