r   e   k   l   a   m   a
r   e   k   l   a   m   a

Aplikacje KDE nie pozwolą na roota. Bezpieczeństwo ponad wolność

Strona główna AktualnościOPROGRAMOWANIE

Jeszcze nie tak dawno na stronach KDE wiodącym hasłem było „Experience Freedom!” („doświadcz wolności”). I faktycznie, pod względem wolności dawanej swoim użytkownikom, to środowisko graficzne było bezkonkurencyjne. Było i jest – ale czy będzie dalej? Hasło zniknęło, zastąpił je slogan o przyjaznym doświadczeniu użytkownika, a w imię tej przyjazności zaczynają być podejmowane przez deweloperów KDE decyzje, które jakby temu doświadczeniu wolności przeczą.

Użytkownicy OpenSUSE, dystrybucji od zawsze świetnie dopracowanej pod kątem implementacji KDE, skarżą się na niemożliwość uruchomienia menedżera plików Dolphin z uprawnieniami roota. Problem dotyczy jednak nie tylko OpenSUSE, to samo dzieje się we wszystkich dystrybucjach, w których pojawiła się najnowsza wersja pakietu KDE Applications 17.04.0. Menedżer plików otrzymał w niej kilka ulepszeń (na czele ze zrobieniem porządku z menu kontekstowym panelu Miejsca), ale stał się bezużyteczny dla wszystkich tych, którzy chcieli go wykorzystać do wprowadzenia zmian w plikach systemowych.

Wprowadzona łatka po prostu sprawdza, czy aplikacja jest uruchamiana z uprawnieniami roota, a jeśli tak, to jej uruchomienie zostaje przerwane, z komunikatem Executing Dolphin as root is not possible (uruchomienie Dolphina jako root jest niemożliwe). Nie ma znaczenia, czy uruchomimy menedżer plików przez sudo, kdesu, dbus-launch czy z graficznego środowiska roota. Sprawa jest o tyle niepoważna, że Dolphin jest domyślnym menedżerem plików KDE, więc w tym momencie na „czystym” systemie administrator po uruchomieniu graficznej sesji w ogóle nie ma dostępu do podstawowego menedżera plików.

r   e   k   l   a   m   a

Problem dotyczy nie tylko Dolphina, także inne aplikacje KDE przestały działać z uprawnieniami roota – włącznie z edytorem tekstu kwrite/kate. Martin Gräßlin, który od dawna był zwolennikiem takiej blokady, tłumaczy, że to wszystko dla bezpieczeństwa użytkowników, dostęp do plików z uprawnieniami roota w graficznych aplikacjach korzystających z licznych bibliotek (Qt, ale też Xlib, xcb, OpenGL itd.) jest ekstremalnie niebezpieczny. Faktycznie, każde okno aplikacji X11 ma pełno właściwości, do których może pisać każdy proces – nie ma tu żadnych mechanizmów kontroli dostępu i zaufania.

Sęk jednak w tym, że rozwiązanie proponowane przez Gräßlina, tj. używanie narzędzia sudoedit, które wywołuje edytor (domyślnie vi), w tle przeprowadzając operację na pliku tymczasowym, którym później nadpisywany jest później oryginał. Nie jest to jednak póki co ani wygodne, ani dobrze zintegrowane z powłoką graficzną. Deweloper KDE zapewnia jednak, że jest to lepsze, gdyż pozwala uruchomić edytor z własnym stylem graficznym, działa z Waylandem – i oczywiście jest bezpieczne.

Może i jest bezpieczne, ale bezpieczeństwo to zapewniono w dość ordynarny sposób, znacząco utrudniając użytkownikom operacje na plikach systemowych (szczególnie gdy jako domyślny edytor ustawiony jest vi, którego wielu linuksowych nowicjuszy po prostu nie umie). Właściwe rozwiązanie powinno korzystać z systemowego mechanizmu zarządzania prawami użytkownika, tj. PolicyKit, w połączeniu np. z wirtualnym systemem plików KIO. To pozwoliłoby zachować dotychczasowe przyzwyczajenia, nie ograniczając wolności użytkownika – i nie czynić bezużytecznymi te wszystkie poradniki dla początkujących, w których unikano konsoli, polecając uruchomienie narzędzi graficznych z uprawnieniami roota.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.