Linux jakby rozmiękczony
-
- 02.05.2005
Dzięki sudo hasło superużytkownika nie musi być znane zwykłemu użytkownikowi do wykonywania uprzednio skonfigurowanych czynności wymagających UID 0. Sudo świetnie się sprawdza przy oprogramowaniu takim jak xsane, gdzie trzeba załadować firmware do skanera, a także wszelkich czynności, w których istotne jest delegowanie uprawnień. Su stosuje się wtedy, gdy użytkownik (zazwyczaj jest nim sam administrator) zna hasło superużytkownika i logowanie na to konto nie jest zablokowane. Innym zastosowaniem jest uruchomienie procesu z innymi uprawnieniami (np. użytkownika nobody czy oracle) w skrypcie, który normalnie jest uruchamiany z uprawnieniami systemowymi.
Sudo podlega konfiguracji przez administratora (komenda visudo), a potem umożliwia wybranym użytkownikom bardzo łatwe użycie podwyższonych uprawnień. Dobrze ustawione sudo w zasadzie eliminuje konieczność używania su przez użytkowników, podobnie nie muszą oni znać hasła administracyjnego. Ponadto można logować aktywność użytkowników i rejestrować wszelkie użycie sudo - zakończone powodzeniem lub nie.
Najpoważniejszym niedostatkiem jest brak naprawdę dobrych narzędzi do łatwej konfiguracji sudo.
Przydałaby się aplikacja będąca na przykład fragmentem Centrum Sterowania, w której coś w rodzaju konsoli administracyjnej umożliwiałoby wybór opcji konfiguracji sudo. Po zakończeniu ustawień program ten mógłby tworzyć właściwy plik konfiguracyjny usługi sudo. Póki co warto skorzystać z dobrego artykułu na temat sudo tutaj:http://www.aplawrence.com/Basics/sudo.html oraz nahttp://www.linux-magazine.pl/issue/02/LinuxUser_command.pdf .
Jedną z dystrybucji, która bardzo skutecznie korzysta z sudo i su, jest Ubuntu. Często stosowane ustawienia tej dystrybucji zakładają zablokowanie konta root do interaktywnego logowania. Oznacza to, że nie można się zalogować na użytkownika root w ogóle! Wszystkie czynności wymagające użycia uprawnień systemowych są wykonywane za pomocą sudo. To dobre rozwiązanie, ponieważ daje dostateczną kontrolę nad wykonywanymi poleceniami, ponadto wyrabia w użytkownikach nawyk pracy na możliwie niskich uprawnieniach, co jest jednym z warunków bezpieczeństwa.
Łatwo i niebezpiecznie
Jak widać, w systemie Linux są dostępne narzędzia dające możliwość ułatwienia pracy przy zachowaniu niezbędnego poziomu bezpieczeństwa, ale trzeba umieć i chcieć z nich skorzystać. Linux na stacjach roboczych jest jeszcze rzadkością, chociaż zdarzają się zakończone sukcesem wdrożenia tego systemu w firmach, także w Polsce. Użytkownicy indywidualni będą masowo korzystać z dystrybucji typu Linspire, gdyż dzięki takim właśnie dystrybucjom przesiadka na inny system operacyjny jest łatwa. Niemniej, firmy oraz bardziej świadomi użytkownicy powinni zainteresować się dystrybucją, która traktuje bezpieczeństwo poważniej.
Oprócz programów su i sudo, są jeszcze znane od dawna atrybuty setuid i setgid, które dają możliwość uruchomienia programu z uprawnieniami właściciela lub grupy danego pliku. Opcje te nie dają jednak takiej możliwości konfiguracji ani audytu nieuprawnionego użycia jak sudo, niemniej w wielu programach są używane. Niestety, każdy kij ma dwa końce - program posiadający atrybut setuid, którego właścicielem jest root, może stanowić potencjalne niebezpieczeństwo. Błąd w takim programie może dać możliwość uruchomienia powłoki (albo dowolnego innego polecenia) z uprawnieniami roota.
Setuid najczęściej stosuje się tam, gdzie wszyscy użytkownicy mają mieć prawo uruchomienia danego programu z innymi poświadczeniami. Co prawda nie daje łatwej możliwości logowania użycia, ale jest proste i przezroczyste dla skryptów wywołujących to polecenie. Są czasami programy, które nie powinny pracować z uprawnieniami setuid root (np. gnokii), ale nie tylko. Ponadto setuid raczej nie nadaje się do wykonywania skryptów z uprawnieniami roota.
Takich rozwiązań lepiej unikać, a zamiast nich lepiej skorzystać z sudo. Zresztą sam program sudo jest tak naprawdę zainstalowany jako setuid root, ponieważ zakłada uruchomienie procesu z innymi poświadczeniami. Po zakończeniu konfiguracji narzędzi do kontrolowanego podnoszenia uprawnień, warto całkowicie zablokować zalogowanie się poprzez SSH na konto root (opcja PermitRootLogin).
