Sudo i sudoers w Gentoo
1.
Czym jest sudo?
Nadawanie uprawnień
Pakiet app-admin/sudo pozwala administratorowi systemu nadać zwykłym
użytkownikom uprawnienia do uruchamiania programów, do których normalnie nie
mieliby dostępu. W odróżnieniu od ustawiania bitu setuid na tych
programach w celu umożliwienia uruchomienia ich z uprawnieniami
administratora, sudo pozwala precyzyjnie określić kto może
wykonać daną komendę i kiedy.
Za pomocą sudo administrator może utworzyć listę osób, które mogą
uruchamiać pewne programy. W przypadku, jeśli na programie zostałby ustawiony
jedynie bit setuid, dowolny użytkownik mógłby uruchomić dany program
(ewentualnie dowolny użytkownik z pewnej grupy, zależnie od ustawionych na
pliku uprawnień). Używając sudo, można (i jest dobrą praktyką)
wymagać od użytkownika podania hasła do uruchomienia danego programu; można
nawet określić dokładnie uprawnienia na podstawie lokalizacji, z której
użytkownik się loguje (np. czy jest zalogowany lokalnie czy poprzez zdalną
sesję SSH).
Logowanie czynności
Dodatkową zaletą stosowania sudo jest jego możliwość logowania każdej
próby (udanej bądź nie) uruchomienia programu. Okazuje się to bardzo
przydatne, jeśli istnieje potrzeba sprawdzenia, kto popełnił ten fatalny błąd,
którego skutków usuwanie trwało dziesięć godzin. :)
Konfiguracja sudo
Konfiguracja sudo znajduje się w pliku /etc/sudoers.
Nie należy tego pliku edytować za pomocą komendy nano /etc/sudoers,
vim /etc/sudoers ani żadnym innym ulubionym edytorem. Jeśli istnieje
potrzeba zmiany tego pliku, należy posłużyć się komendą visudo.
Jest to narzędzie, które gwarantuje, że dwóch administratorów systemu nie będzie
edytować tego pliku w tym samym momencie, zapewnia zachowanie odpowiednich bitów
uprawnień na edytowanym pliku i sprawdza w podstawowym stopniu składnię,
gwarantując, że w pliku nie powstaną fatalne w skutkach błędy. W praktyce
uruchamia ono edytor zdefiniowany w zmiennej środowiskowej EDITOR, która w
Gentoo domyślnie jest definiowana w pliku /etc/rc.conf.
O tym tekście
Ten tekst jest pomyślany jako krótkie wprowadzenie w tematykę sudo.
Pakiet ten ma znacznie większe możliwości niż te, które są tutaj opisane.
Pozwala m.in. edytować pliki z uprawnieniami innego użytkownika
(sudoedit), uruchamiać programy ze skryptów w taki sposób, żeby mogły
przejść do tła, odczytać hasło ze standardowego wejścia zamiast klawiatury
itd...
Więcej informacji na temat sudo i sudoers znajduje się na ich stronach man.
2.
Składnia pliku sudoers
Podstawowa składnia
Zwykle najtrudniejszym zadaniem w poznaniu sudo jest przyzwyczajenie się
do składni pliku /etc/sudoers. W najprostszym wydaniu wygląda ona w
ten sposób:
Listing 2.1: Podstawowa składnia /etc/sudoers |
użytkownik komputer = komenda
|
Taka składnia instruuje sudo, że użytkownik określony przez wpis
użytkownik zalogowany z maszyny komputer może wykonywać
komendę z uprawnieniami superużytkownika. Konkretny przykład pokaże to
lepiej: pozwólmy użytkownikowi antoni wykonać komendę emerge tylko
jeśli jest zalogowany lokalnie (nie poprzez SSH):
Listing 2.2: Realny przykład /etc/sudoers |
antoni localhost = /usr/bin/emerge
|
Ostrzegamy, że nie należy pozwalać użytkownikom na wykonywanie
programów, które pozwalają na zwiększenie ich przywilejów w systemie. Na
przykład użytkownik mający prawo do wykonanie emerge z prawami
superużytkownika, może je wykorzystać do zdobycia pełnej kontroli nad systemem.
Użytkownikom, którym się nie ufa nie należy nadawać żadnych przywilejów poprzez
sudo.
Nazwę użytkownika można zastąpić nazwą grupy. W takim przypadku nazwę grupy
należy poprzedzić znakiem %. W przykładzie poniżej pozwolimy na
korzystanie z emerge wszystkim członkom grupy wheel:
Listing 2.3: Udzielanie członkom grupy wheel prawa do wykonywania polecenia emerge |
%wheel localhost = /usr/bin/emerge
|
Można rozszerzyć pojedynczy wpis o wiele komend (zamiast tworzyć oddzielne wpisy
dla każdej komendy). Na przykład, żeby pozwolić przykładowemu użytkownikowi
uruchamiać nie tylko emerge, ale również polecenia ebuild i
emerge-webrsync jako superużytkownik, należy wpisać:
Listing 2.4: Zezwolenie na wykonanie wielu komend |
antoni localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync
|
Można również określić całą komendę z jej parametrami, a nie tylko samą ścieżkę
pliku wykonywalnego. Jest to przydatne, jeżeli istnieje potrzeba ograniczenia
wykonywania komendy tylko do pewnych opcji. W sudo istnieje możliwość
skorzystania ze znaków zastępczych tak jak w powłoce, ale nie można
korzystać w nim z wyrażeń regularnych.
Spróbujmy:
Listing 2.5: Próba uaktualnienia systemu poprzez sudo |
$ sudo emerge -uDN world
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Password:
|
Hasło, którego wymaga sudo jest domyślnie własnym hasłem użytkownika.
Upewni nas to, że pozostawiony przypadkowo bez opieki terminal nie zostanie
wykorzystany przez nikogo do złych celów.
Należy mieć na uwadze, że sudo nie zmienia zawartości zmiennej
środowiskowej ${PATH. Dowolna polecenie umieszczone po sudo jest
uruchamiane w środowisku użytkownika. Jeśli użytkownik musi uruchomić jakieś
polecenie, np. z katalogu /sbin, powinien sudo podać pełną ścieżkę
(chyba, że ma już /sbin we własnej zmiennej ${PATH}):
Listing 2.6: Użycie pełnej ścieżki do programu |
$ sudo /usr/sbin/emerge-webrsync
|
Posługiwanie się aliasami
W większych systemach potrzeba wprowadzania wszystkich użytkowników ze
wszystkimi kombinacjami komend i komputerów może być nieco przerażającym
zajęciem. Aby ułatwić administrację pliku /etc/sudoers można
definiować aliasy. Sposób deklaracji aliasów jest prosty:
Listing 2.7: Deklaracja aliasów w /etc/sudoers |
Host_Alias hostalias = hostname1, hostname2, ...
User_Alias useralias = user1, user2, ...
Cmnd_Alias cmndalias = command1, command2, ...
|
Aliasem, który jest zawsze zdefiniowany, dla dowolnej kategorii jest alias
ALL (aby ułatwić rozróżnienie pomiędzy aliasami i nie-aliasami dobrą
praktyką jest używać wielkich liter w nazwach aliasów). Jak nietrudno zgadnąć,
alias ALL jest aliasem wszystkich możliwych wartości.
Dobrym przykładem użycia aliasu ALL jest zezwolenie dowolnemu
użytkownikowi na użycie komendy shutdown, pod warunkiem, że użytkownik
jest zalogowany lokalnie:
Listing 2.8: Zezwolenie na wykonanie komendy shutdown |
ALL localhost = /sbin/shutdown
|
Innym przykładem mogłoby być zezwolenie użytkownikowi antoni na
wykonywanie komendy emerge, niezależnie od tego z jakiej maszyny jest
zalogowany:
Listing 2.9: Zezwolenie na wykonywanie programu niezależnie od lokalizacji |
antoni ALL = /usr/bin/emerge
|
Bardziej interesującym przykładem jest zdefiniowanie grupy użytkowników, którzy
mogą uruchamiać programy administracyjne (takie jak emerge i
ebuild) i grupy administratorów, którzy mogą zmieniać hasła użytkownikom
- ale nie superużytkownikowi!
Listing 2.10: Użycie aliasów dla użytkowników i komend |
User_Alias SOFTWAREMAINTAINERS = antoni, john, danny
User_Alias PASSWORDMAINTAINERS = antoni, sysop
Cmnd_Alias SOFTWARECOMMANDS = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias PASSWORDCOMMANDS = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root
SOFTWAREMAINTAINERS localhost = SOFTWARECOMMANDS
PASSWORDMAINTAINERS localhost = PASSWORDCOMMANDS
|
Uruchamianie komend z uprawnieniami innego zwykłego użytkownika
Użytkownicy mają również możliwość wykonywania komend z uprawnieniami innych
zwykłych użytkowników (nie superużytkownika). Może to być bardzo przydatne,
jeśli są w systemie uruchomione programy z uprawnieniami pewnego użytkownika
(np. apache dla serwera WWW) i istnieje potrzeba wykonywania przy tych
programach czynności administracyjnych przez pewnych użytkowników (np. zabicie
procesów zombie).
Wewnątrz pliku /etc/sudoers umieszcza się użytkownika
(użytkowników) pomiędzy ( i ) przed listą komend:
Listing 2.11: Wykonywanie jako ktoś inny niż superużytkownik |
użytkownik komputer = (uruchom-jako) komendy
|
Na przykład, żeby umożliwić użytkownikowi antoni wykonanie komendy
kill jako użytkownik apache albo rane:
Listing 2.12: Przykład zezwolenia na wykonywanie jako nie-superużytkownik |
Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill
antoni ALL = (apache, rane) KILL
|
Z takim ustawieniem, użytkownik może wybrać, z uprawnieniami jakiego użytkownika
uruchomi komendę sudo -u:
Listing 2.13: Wykonanie pkill jako użytkownik apache |
$ sudo -u apache pkill apache
|
Można stworzyć alias definiujący użytkowników, z których uprawnieniami będzie
można uruchamiać programy używając dyrektywy Runas_Alias. Jej użycie jest
identyczne jak pozostałych aliasów omówionych wcześniej.
Hasła i ustawienia domyślne
Domyślnie sudo prosi użytkownika o podanie jego własnego hasła w celu
identyfikacji. Po jednorazowym podaniu hasła sudo pamięta je przez pięć
minut, pozwalając użytkownikowi skupić się na swojej pracy raczej niż na
ciągłym wprowadzaniu hasła.
To zachowanie może być oczywiście zmienione. Używając dyrektywy
Defaults: w pliku /etc/sudoers można zdefiniować domyślne
zachowanie dla danego użytkownika.
Na przykład, żeby zmienić domyślne pięć minut na zero (nigdy nie zapamiętuj
hasła):
Listing 2.14: Zmiana czasu ważności hasła |
Defaults:antoni timestamp_timeout=0
|
Wartość -1 powodowałaby bezterminowe zapamiętanie hasła (do czasu
restartu systemu).
Można też zdefiniować ustawienie wymagające podania hasła użytkownika, z którego
uprawnieniami komenda ma być uruchomiona, a nie własnego hasła. Osiąga się to
przez użycie opcji runaspw. W poniższym przykładzie ustalamy również
ilość dozwolonych pomyłek we wprowadzaniu hasła (czyli ilość razy z jaką hasło
może być wprowadzana zanim sudo zakończy swe działanie z błędem), zamiast
domyślnych trzech:
Listing 2.15: Wymóg podania hasła użytkownika, zamiast własnego |
Defaults:john runaspw, passwd_tries=2
|
Kolejną interesującą cechą jest możliwość utrzymywania zmiennej DISPLAY
ustawionej tak, abyśmy mogli uruchamiać narzędzia graficzne:
Listing 2.16: Utrzymywanie zmiennej DISPLAY |
Defaults:john env_keep=DISPLAY
|
Za pomocą dyrektywy Defaults: można zmienić całe tuziny domyślnych
ustawień. Więcej informacji można znaleźć w man sudoers - szukając wpisu
dotyczącego Defaults.
Jeśli natomiast istnieje potrzeba zezwolenia użytkownikowi na wykonywanie komend
bez podawania jakiegokolwiek hasła, należy te komendy poprzedzić opcją
NOPASSWD:, w taki sposób:
Listing 2.17: Zezwolenie na uruchamianie emerge bez monitowania o hasło |
antoni localhost = NOPASSWD: /usr/bin/emerge
|
3.
Użytkowanie sudo
Sprawdzanie uprawnień
Aby dowiedzieć się, jakie posiada się uprawnienia, należy uruchomić
sudo -l:
Listing 3.1: Sprawdzanie uprawnień |
$ sudo -l
User antoni may run the following commands on this host:
(root) /usr/libexec/xfsm-shutdown-helper
(root) /usr/bin/emerge
(root) /usr/bin/passwd [a-zA-Z0-9_-]*
(root) !/usr/bin/passwd root
(apache) /usr/bin/pkill
(apache) /bin/kill
|
Jeśli w /etc/sudoers są zdefiniowane komendy nie wymagające
podawania żadnego hasła, ich wylistowanie też nie będzie wymagało hasła. W innym
przypadku użytkownik zostanie poproszony o podanie hasła, jeśli nie jest ono
zapamiętane przez sudo.
Wydłużanie czasu ważności hasła
Domyślnie, jeśli użytkownik podał swoje hasło w celu uwierzytelnienia się przed
sudo, jest ono pamiętane przez pięć minut. Jeśli użytkownik chce wydłużyć
ten czas, może uruchomić sudo -v, żeby wyzerować licznik czasu
ważności hasła. W takim przypadku minie kolejne pięć minut, zanim sudo
znów poprosi o hasło.
Listing 3.2: Wydłużanie czasu ważności hasła |
$ sudo -v
|
Odwrotny skutek odniesie sudo -k: hasło zostanie zapomniane
natychmiast.
Materiał udostępniany na podstawie licencji Creative Commons -
Attribution / Share Alike.
|