Jak uruchamiać usługi bez uprawnień root

Dlaczego nie należy uruchamiać wszystkiego jako root

Użytkownik root posiada pełne uprawnienia w systemie: może odczytać każdy plik, zmienić dowolną konfigurację lub usunąć cały system. Uruchomienie usługi jako root przekazuje te uprawnienia danej usłudze. Jeśli w usłudze wystąpi błąd podatny na eksploatację, napastnik przejmuje pełną kontrolę nad serwerem. Uruchamianie procesów jako użytkownik o ograniczonych uprawnieniach ogranicza zakres ewentualnych szkód. Błąd w usłudze działającej na koncie o ograniczonych uprawnieniach daje napastnikowi dostęp wyłącznie do zasobów, do których dostęp posiada to konto, czyli w praktyce do niemal niczego.

Jest to zasada najniższych uprawnień (principle of least privilege): każda część systemu powinna posiadać dokładnie takie uprawnienia, jakie są niezbędne do wykonania jej zadań, i nic więcej. Jest to najskuteczniejsza metoda ograniczania skutków naruszenia bezpieczeństwa, a w nowoczesnych serwerach jej wdrożenie nie generuje niemal żadnych kosztów.

Dedykowane konto dla każdej usługi

Klasycznym podejściem jest utworzenie osobnego systemowego użytkownika dla każdej usługi, który posiada uprawnienia wyłącznie do plików danej usługi i nie może się zalogować. Systemowe konto dla aplikacji webowej może wyglądać następująco:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

Każda flaga ma znaczenie. --system definiuje konto jako konto systemowe, a nie konto użytkownika. --no-create-home pomija tworzenie katalogu domowego, który nie jest wymagany. --shell /usr/sbin/nologin sprawia, że nawet po przejęciu konta napastnik nie będzie mógł otworzyć powłoki (shell). Konto służy wyłącznie do zarządzania procesem i jego plikami.

Następnie należy nadać temu użytkownikowi wyłącznie niezbędne pliki:

sudo chown -R appsvc:appsvc /opt/myapp

W takim układzie usługa odczytuje i zapisuje pliki we własnym katalogu i nie ma dostępu do żadnych innych miejsc na dysku. W przypadku eksploatacji, zakres plików dostępnych do modyfikacji przez napastnika ogranicza się do /opt/myapp; konto nadal może odczytywać pliki dostępne dla wszystkich (world-readable), ale nie może modyfikować reszty systemu.

Uruchamianie przez systemd jako dany użytkownik

Po utworzeniu konta należy skonfigurować systemd, aby uruchamiał usługę jako ten użytkownik. W pliku jednostki (unit file) wystarczy jedna linia:

[Service]
ExecStart=/opt/myapp/bin/server
User=appsvc
Group=appsvc

User=appsvc oznacza, że proces startuje z ograniczonymi uprawnieniami tego konta zamiast uprawnień roota. Jest to standardowa i zalecana metoda uruchamiania aplikacji w systemd, którą należy stosować dla każdej tworzonej jednostki.

Lub całkowite pominięcie konta dzięki DynamicUser

systemd może tworzyć tymczasowego użytkownika, który istnieje tylko podczas działania usługi. Używając DynamicUser=yes, nie trzeba zarządzać kontem w ogóle:

[Service]
ExecStart=/opt/myapp/bin/server
DynamicUser=yes
StateDirectory=myapp

Podczas startu systemd przydziela nieużywany identyfikator użytkownika (UID), a po zatrzymaniu usługi zwalnia go. Usługa otrzymuje również prywatny /tmp (odczytywalny widok większości systemu plików) oraz zapisalny katalog stanu w /var/lib/myapp, który jest przygotowywany przez StateDirectory=. Dla samodzielnych usług, które wymagają jedynie własnego katalogu stanu, DynamicUser=yes jest najprostszym sposobem na uzyskanie silnej izolacji, ponieważ nie istnieje żadne długotrwałe konto, które mogłoby stać się celem ataku.

Ręczne tworzenie jednostek jest pracochłonne, a kluczowe jest poprawne stosowanie dyrektyw wzmacniających bezpieczeństwo (hardening). Generator w przewodniku po usługach i timerach systemd może automatycznie uzupełnić te opcje, zapewniając poprawność jednostki.

Relacja z pozostałymi mechanizmami

Zasada najniższych uprawnień to jedna warstwa, która współpracuje z innymi, zamiast je zastępować. Domyślnie blokujący firewall kontroluje, co może dotrzeć do usługi; uruchamianie usługi jako użytkownik o ograniczonych uprawnieniach ogranicza działania usługi w przypadku włamania; a utwardzony SSH zapobiega dostępowi napastników do maszyny. Żaden z tych mechanizmów nie jest wystarczający samodzielnie, ale razem zapewniają, że błąd w jednej usłudze nie doprowadzi do przejęcia całego serwera.

Przed przejściem do dalszych kroków należy przejść przez listę kontrolną wzmacniania bezpieczeństwa (hardening checklist) dla całego systemu i wygenerować jej spersonalizowaną kopię:

FAQ

Dlaczego nie należy uruchamiać usługi jako root?

Ponieważ root ma pełną kontrolę nad maszyną. Eksploatacja usługi działającej jako root daje napastnikowi pełną kontrolę nad całym serwerem, a nie tylko nad samą usługą. Należy rezerwować uprawnienia roota dla celów administracyjnych, a każdą długotrwałą usługę uruchamiać jako użytkownik o ograniczonych uprawnieniach.

Jak utworzyć użytkownika, który nie może się zalogować?

Należy użyć polecenia sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME. Shell nologin uniemożliwia otwarcie sesji interaktywnej nawet w przypadku kradzieży poświadczeń, --system oznacza konto systemowe, a --no-create-home pomija tworzenie zbędnego katalogu domowego. Własność nad plikami należy ograniczyć wyłącznie do własnych zasobów usługi za pomocą chown.

Czym jest systemd DynamicUser?

DynamicUser=yes instruuje systemd, aby utworzył tymczasowego użytkownika dla usługi, który istnieje tylko podczas jej działania, co eliminuje konieczność zarządzania długotrwałym kontem. Funkcja ta zapewnia usłudze prywatny /tmp (widok systemu plików w trybie głównie do odczytu) oraz zarządzany katalog stanu. Jest to najprostsza metoda uruchamiania samodzielnych usług pod tymczasową tożsamością o niskich uprawnieniach.

Czy uruchamianie jako użytkownik nie-root zastępuje firewall?

Nie. Mechanizmy te chronią przed różnymi zagrożeniami. Użytkownik o ograniczonych uprawnieniach ogranicza skutki włamania do usługi, natomiast firewall ogranicza możliwość nawiązania połączenia z usługą. Należy stosować oba rozwiązania oraz utwardzony SSH, aby każda warstwa zabezpieczała to, czego nie zapewnia kolejna.

Jakie pliki powinien posiadać na własność użytkownik usługi?

Wyłącznie pliki niezbędne do działania usługi i nic więcej. Należy nadać użytkownikowi własność nad jego katalogiem roboczym i danymi, pozostawiając resztę plików w posiadaniu roota. Dobrym wzorcem jest sudo chown -R svc-app:svc-app /opt/svc-app dla katalogu aplikacji, podczas gdy konfiguracja w /etc pozostaje własnością roota i jest dostępna dla usługi tylko do odczytu. Celem jest sytuacja, w której przejęcie procesu ogranicza możliwość modyfikacji plików jedynie do własnych danych usługi, a nie do całego systemu.