sudo i minimalne uprawnienia

Moduł 3: Użytkownicy, uprawnienia i sudo · Czas czytania: 11 min

Cel lekcji: Po tej lekcji będą Państwo potrafili pracować jako zwykły użytkownik z sudo, bezpiecznie dodać administratora, zmienić ustawienia sudo bez odcięcia sobie dostępu oraz wyjaśnić, dlaczego minimalne uprawnienia chronią serwer.

Kluczowe pojęcia: sudo, grupa sudo, grupa wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, blokowanie konta root, log sudo, minimalne uprawnienia (least privilege), użytkownik usługi

Dlaczego nie pracować po prostu jako root?

Po instalacji często logują się Państwo jako root. To wygodne: wszystko jest dozwolone. Ale właśnie w tym tkwi problem:

• Wystarczy jedna literówka. rm -rf / home/anna/oud (proszę zwrócić uwagę na spację po pierwszym ukośniku) uruchomione jako root kasuje cały serwer. Jako zwykły użytkownik otrzymają Państwo komunikat o błędzie.
• Wszystko działa jako root. Skrypt wklejony z internetu, testowany program: wszystko otrzymuje pełne uprawnienia.
• Brak śladu. Jeśli trzy osoby pracują jako root, nikt później nie wie, kto co zrobił.
• Root to nazwa, którą próbuje każdy atakujący. Logowanie jako root najlepiej całkowicie wyłączyć (lekcja 2.2), ale można to zrobić dopiero wtedy, gdy mają Państwo inną drogę do uprawnień administratora.

Tą inną drogą jest sudo: logują się Państwo na własne konto i tylko przed poleceniem, które wymaga uprawnień administratora, dopisują sudo.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Ubuntu od wersji 25.10 domyślnie używa sudo-rs, nowej implementacji sudo. W zakresie wszystkiego, co omawia ta lekcja, działa ona tak samo.)

sudo pyta o Państwa hasło, a nie o hasło roota. Następnie domyślnie zapamiętuje je przez kwadrans, aby nie trzeba było go podawać przy każdym poleceniu. Każde polecenie wykonane przez sudo trafia do logu.

Tworzenie administratora

W Debianie i Ubuntu każdy członek grupy sudo może przez sudo wykonać wszystko. Określa to plik /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Należy to czytać tak: członkowie grupy sudo (%) mogą na wszystkich maszynach (ALL) jako dowolny użytkownik i dowolna grupa ((ALL:ALL)) wykonać każde polecenie (ALL).

Dodanie administratora odbywa się więc w dwóch krokach, jako root:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Następnie proszę umieścić klucz publiczny Anny w /home/anna/.ssh/authorized_keys z właściwym właścicielem i uprawnieniami:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

Proszę nie zapomnieć o chown: plik skopiowany przez roota należy do roota, a wtedy Anna nie zaloguje się swoim kluczem.

Teraz, pozostawiając otwartą sesję roota, proszę przetestować w drugim oknie:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Dopiero gdy to działa, ustawiają Państwo w konfiguracji SSH PermitRootLogin no (lekcja 2.2). Od tej chwili logują się Państwo zawsze jako Anna.

Warto zapamiętać jedną rzecz: Anna potrzebuje teraz hasła do sudo. Proszę przechowywać je w menedżerze haseł. Logowanie odbywa się kluczem, sudo hasłem: to dwie różne rzeczy, które włamywacz musi zdobyć obie.

Zmiana ustawień sudo: zawsze przez visudo

Błąd w /etc/sudoers może sprawić, że sudo w ogóle przestanie działać. Jeśli root również nie może się zalogować, utknęli Państwo. Dlatego ustawień sudo nigdy nie edytuje się zwykłym edytorem, lecz za pomocą visudo. Otwiera ono tymczasową kopię i sprawdza zawartość przed zapisaniem:

root@web1:~# visudo -f /etc/sudoers.d/backup

Podobnie jak przy SSH, lepiej używać własnego pliku w /etc/sudoers.d/ niż pliku głównego. Proszę pamiętać o dwóch zasadach tego katalogu:

• Pliki, których nazwa zawiera kropkę lub kończy się na ~, są pomijane. backup.conf więc nie zadziała, a backup tak. Ma to na celu ignorowanie kopii tworzonych przez edytory, ale zaskakuje wiele osób.
• Plik musi należeć do roota i nie może być zapisywalny dla innych (zwykle 440; visudo to załatwia).

Jeśli chcą Państwo sprawdzić istniejący plik bez edytowania: visudo -c sprawdza wszystko.

NOPASSWD: wygodne, ale trzeba wiedzieć, co się robi

Z NOPASSWD sudo nie pyta już o hasło:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Niektóre obrazy VPS ustawiają to dla domyślnego użytkownika, aby po zalogowaniu kluczem od razu mieć uprawnienia administratora. Za pomocą sudo -l mogą Państwo sprawdzić, co obowiązuje u Państwa. Skutek: kto ma klucz Anny, od razu jest rootem. Nie ma już drugiego zabezpieczenia. Na serwerze osobistym można się na to zdecydować, ale należy zrobić to świadomie.

Znacznie lepiej stosować NOPASSWD tylko dla jednego konkretnego polecenia, na przykład dla skryptu kopii zapasowej, który musi działać automatycznie:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

Użytkownik backup może wtedy uruchomić jako root dokładnie ten jeden skrypt, bez hasła, i nic poza tym. Dwie pułapki:

• Zawsze proszę podawać pełną ścieżkę. Przy samym maak-backup ktoś może umieścić własny program o tej nazwie na początku swojej ścieżki.
• Sam skrypt nie może być zapisywalny dla tego użytkownika. W przeciwnym razie zmieni go i uruchomi dowolne polecenia jako root. To samo dotyczy poleceń, które same potrafią otworzyć powłokę, takich jak edytor (vim, nano) lub less: kto może je uruchomić przez sudo, może z poziomu programu otworzyć powłokę roota. Takich poleceń nigdy nie należy udostępniać osobno przez sudo.

Co jest rejestrowane

Za każdym razem, gdy ktoś używa sudo, w journalu pojawia się wpis (a w systemach z rsyslog również w /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Widać, kto, gdzie, jako kto i jakie polecenie. To jeden z powodów, by kilka osób nie pracowało jako root. Nieudane próby sudo („incorrect password attempts”) z konta, które nie należy do Państwa, są sygnałem alarmowym.

Minimalne uprawnienia w szerszym ujęciu

sudo to jedno z zastosowań ogólnej zasady: minimalnych uprawnień (least privilege). Każdy użytkownik i każda usługa otrzymuje dokładnie te uprawnienia, które są potrzebne, i nic więcej. Na serwerze oznacza to między innymi:

• pracują Państwo jako zwykły użytkownik i używają sudo tylko wtedy, gdy jest to konieczne;
• każda usługa działa pod własnym użytkownikiem bez powłoki (lekcja 3.1), a nie jako root;
• aplikacja internetowa otrzymuje użytkownika bazy danych, który ma dostęp tylko do własnej bazy, a nie konto administratora serwera baz danych;
• skrypt kopii zapasowej może wykonać tylko to jedno polecenie, którego potrzebuje (NOPASSWD z pełną ścieżką);
• współpracownik, który tylko aktualizuje stronę, otrzymuje prawo zapisu do /var/www/example.com przez grupę, a nie sudo.

Idea jest taka: jeśli coś pójdzie źle (luka we wtyczce, skradziony klucz), szkoda ogranicza się do tego jednego użytkownika lub usługi. Ta zasada wraca wielokrotnie w zaleceniach CIS i w lekcji o hardeningu (10.1).

W AlmaLinux i Rocky Linux

Tam grupa administratorów nazywa się wheel zamiast sudo: usermod -aG wheel anna. Wpis w /etc/sudoers to %wheel ALL=(ALL) ALL. visudo i /etc/sudoers.d działają tak samo. Komunikaty sudo znajdują się tam również w /var/log/secure.

Podsumowanie

• Proszę pracować jako zwykły użytkownik i używać sudo do administracji; sudo pyta o Państwa własne hasło i rejestruje każde polecenie.
• Tworzenie administratora: adduser anna, adduser anna sudo (wheel w systemach pokrewnych RHEL), klucz z właściwym właścicielem i uprawnieniami, test w drugim oknie, dopiero potem wyłączenie logowania roota.
• Reguły sudo proszę edytować wyłącznie przez visudo, najlepiej we własnym pliku w /etc/sudoers.d/ bez kropki w nazwie.
• NOPASSWD dla wszystkiego usuwa jedno zabezpieczenie; lepiej stosować je tylko dla jednego polecenia z pełną ścieżką, którego użytkownik nie może zmienić.
• Minimalne uprawnienia: każdy użytkownik i każda usługa otrzymuje dokładnie to, co potrzebne, dzięki czemu błąd lub luka pozostają niewielkie.

Quiz

Zadanie

Zadanie O3.2: Administrator z sudo. Proszę utworzyć na swoim serwerze zwykłego administratora (na przykład anna), poprawnie ustawić klucz, przetestować logowanie i sudo -l w drugim oknie, a następnie wyłączyć logowanie roota przez SSH (PermitRootLogin no). Proszę odhaczyć kroki, wkleić wynik id (tylko nazwę i grupy) i odpowiedzieć na pytania: który wpis nadaje administratorowi uprawnienia, czy gdzieś występuje NOPASSWD i jak dostaną się Państwo do serwera, jeśli zapomną hasła?

Przeczytaj więcej

Kroki opisane w tych artykułach dotyczą serwerów VPS WebOké; u innych dostawców działa to podobnie.

• Zabezpieczanie VPS: pierwsze pięć minut
• Brak dostępu do VPS: co teraz?
• Instrukcja DirectAdmin 12.2: Użytkownicy baz danych, uprawnienia i hasła
• Ubuntu Server: User management: https://ubuntu.com/server/docs/how-to/security/user-management/
• Dokumentacja Debiana, sudoers: https://manpages.debian.org/trixie/sudo/sudoers.5.en.html