Zdarza się, że nadanie uprawnień administratorskich w systemach uniksowych jest jednoznaczne z przekazaniem innej osobie hasła roota. Sięgnięcie po to najprostsze rozwiązanie jest jednocześnie dużym błędem.

Przekazanie hasła roota, choć szybkie i efektywne, nie jest poprawną metodą na dopuszczenie do zarządzania danym serwerem nowych osób. Zdecydowanie rozsądniejsze jest wykorzystanie możliwości oferowanych przez mechanizm sudo.

Żeby zrozumieć zalety przydzielania uprawnień za pomocą sudo, warto przeanalizować, jak wygląda praca bez tego mechanizmu. Jeśli na danym serwerze uprawnienia administracyjne ma posiadać wiele osób, to czy wszystkie muszą znać hasło roota? Im więcej osób je zna, tym większe jest ryzyko ujawnienia go kolejnym osobom. Trudno zapanować nad bałaganem, gdy w taki sposób zarządzane są dziesiątki lub więcej serwerów. Hasło roota zna wtedy wiele osób, a każdy serwer może posiadać inną listę osób z dostępem administracyjnym.

> SZEROKI DOSTĘP DO ROOTA

Oprócz osób bezpośrednio zajmujących się serwerami z racji obowiązków najwyższe prawa dostępu często mają także opiekunowie aplikacji i baz danych. Czy może być gorzej? Brak stosowania mechanizmu sudo i znajomość realiów nasuwają na myśl kolejne pytania. Czy wszystkie serwery posiadają jednakowe hasło do kont roota (z pewnością ułatwia to zarządzanie)? W przypadku gdy stosowane hasła różnią się, w jaki sposób i gdzie są przechowywane? I wreszcie czy można ustalić kompletną listę osób znających hasło roota na wybranym serwerze? Kolejny problem pojawia się w sytuacji, gdy z firmy odchodzi pracownik znający hasło roota wielu serwerów. Procedura bezpieczeństwa sugerowałaby zmianę haseł na wszystkich serwerach, do których wspomniana osoba miała dostęp. Pod warunkiem że możliwe jest ustalenie kompletnej listy takich serwerów i wiadomo, komu nowe hasła przekazać. Czasochłonne, narażone na wyciek nowych haseł, niewdzięczne do realizacji zadanie.

> ZALETY MECHANIZMU SUDO

Stosowanie sudo eliminuje powyższe niedogodności i zagrożenia oraz pozwala uporządkować przydzielane prawa dostępu do serwerów. Podstawową zaletą jest to, że sudo nie wymaga rozdawania różnym osobom hasła do konta root. Użytkownik, który został uprawniony do bardziej zaawansowanych lub nieograniczonych operacji w systemie, uwierzytelnia się, korzystając z własnego loginu i hasła. Uzyskuje tym samym możliwość pracy jako root, ale bez potrzeby podawania hasła roota na jakimkolwiek etapie logowania/uwierzytelniania.

Hasło roota może pozostać poufne i być znane tylko bardzo wąskiej i łatwej do identyfikacji grupie osób odpowiadających za utrzymywanie infrastruktury, przy czym poprawna polityka bezpieczeństwa powinna zabraniać bezpośredniego uzyskiwania uprawnień roota (polecenie su -) na rzecz korzystania przez sudo (polecenie sudo su -).

Kolejną z zalet stosowania sudo jest możliwość precyzyjnego określania zakresu podwyższonych uprawnień. Jeżeli nowy pracownik ma otrzymać tylko uprawnienia do zarządzania jedną usługą, to sudo pozwala na taką konfigurację, bez potrzeby nadawania tej osobie nieograniczonych uprawnień w całym systemie. Pracownik może zatem edytować pliki konfiguracyjne danej usługi, sterować nią oraz awaryjnie wyłączać, ale nie ma możliwości instalowania oprogramowania w systemie, sterowania innymi usługami, resetowania haseł kont lokalnych czy zarządzania zasobami dyskowymi. Sudo zapisuje w logu zdarzenia związane z korzystaniem z niego, dzięki czemu da się sprawdzić, kto i kiedy uruchamiał polecenia wykorzystujące ten mechanizm. Upraszcza także odbieranie uprawnień osobom, które już ich nie potrzebują lub np. zmieniają pracę. Wystarczy usunąć konto takiej osoby z konfiguracji sudo lub usunąć to konto z grup posiadających wpisy w pliku konfiguracyjnym sudo. Nie ma potrzeby zmiany haseł roota na serwerach i przekazywania ich innym administratorom.

> PLIK KONFIGURACYJNY SUDOERS

Najlepszym sposobem na zrozumienie konfiguracji sudo jest praktyka, dlatego w dalszej części artykułu pokazujemy przykłady stosowania tego mechanizmu. Plik konfiguracyjny sudo – /etc/sudoers – można otworzyć w dowolnym edytorze tekstu, przy czym takie działanie uniemożliwi korzystanie z istotnych ułatwień. Do edycji najlepiej użyć programu visudo, sprawdzającego poprawność składni. W razie pojawienia się błędu zostanie wyświetlony alert, co jest o tyle ważne, że przypadkowa literówka lub źle dobrana konfiguracja mogą skutkować pozbawieniem uprawnień nawet samego administratora. Program visudo zawsze sprawdza składnię pliku podczas jego zamykania. Wykrycie ewentualnej nieprawidłowości może zostać zgłoszone w następujący sposób:
 

Poprawna edycja pozwala na zapisanie zawartości pliku sudoers bez wyświetlenia dodatkowych komunikatów, a wdrożenie zmian nie wymaga restartowania usług czy całego serwera. Sugerowane jest jedynie oczyszczenie sesji użytkownika, któremu nadajemy podwyższone uprawnienia, poprzez wylogowanie się z systemu i ponowne zalogowanie.

Najprostsza konfiguracja może się składać z czterech elementów:
 

• nazwy użytkownika lub nazwy grupy, która ma otrzymać dane uprawnienia;
• miejsca, których dotyczą uprawnienia (serwer lub serwery);
• listy programów, które mogą być uruchamiane;
• przywilejów, z jakimi dane programy będą uruchamiane.

> SUDO – PRZYKŁADY UŻYCIA
 

• Nadanie użytkownikowi o nazwie Konrad uprawnień do uruchamiania aplikacji o nazwie program1 z przywilejami roota:

konrad ALL = (root) /usr/bin/program1

Taka konfiguracji spowoduje, że użytkownik będzie mógł uruchomić powyższy program, stosując polecenie sudo /usr/bin/program1. Przed uruchomieniem programu mechanizm sudo poprosi użytkownika o uwierzytelnienie się jego hasłem. Aby zrezygnować z konieczności wpisywania hasła, wymagana jest modyfikacja powyższej linii w następujący sposób:

konrad ALL = (root) NOPASSWD: /usr/bin/program1

Brak wymogu dodatkowego uwierzytelniania hasłem wpływa na wygodę korzystania z sudo. Jednocześnie wprowadza pewne ryzyko nieautoryzowanego użycia przez osobę, która uzyska nawet chwilowy dostęp do ekranu osoby zalogowanej do danego serwera i posiadającej na nim uprawnienia do sudo.
 

•  Zezwalanie na uruchamianie określonego programu, ale bez dodatkowych argumentów:

konrad ALL = (root) NOPASSWD: /usr/bin/program1 ""

Użytkownik będzie mógł użyć polecenia sudo /usr/bin/program1, ale nie będzie mógł korzystać z polecenia sudo /usr/bin/program1 arg1 arg2.
 

• Zezwolenia na uruchamianie programu z jednym określonym argumentem /usr/bin/program1 arg1:

konrad ALL = (root) NOPASSWD: /usr/bin/program1 arg1
 

• Nadanie uprawnień do administrowania serwerem:

konrad ALL = (root) ALL

Taka konstrukcja pozwala użytkownikowi na wykonanie polecenia sudo su -, dzięki któremu uzyska on możliwość pracy jako root.
 

• Nadanie uprawnień do wszystkich operacji z prawami roota, z wyjątkiem wskazanego polecenia:

konrad ALL = (root) !/usr/sbin/fdisk

Powyższy wpis pozwala użytkownikowi na niemal nieograniczone działania. Wyjątkiem jest program fdisk, którego dany użytkownik nie będzie mógł uruchamiać.

Sudo może posłużyć nie tylko do uruchamiania poleceń z przywilejami roota. W poniższym przykładzie pokazano konfigurację pozwalającą na uruchamianie skryptu przygotowanego przez innego użytkownika:

[...]

Specjalista ds. utrzymania infrastruktury i operacji. Zajmuje się problematyką budowy i utrzymania centrów przetwarzania danych oraz zarządzania nimi i koordynowaniem zmian dotyczących krytycznej infrastruktury IT.