Capabilities

Podział uprawnień roota na drobne, oddzielnie przyznawane przywileje (np. tylko nasłuch na niskich portach). Pozwala dać procesowi część praw administratora bez pełnego roota.

Linux Capabilities to mechanizm, który rozbija wszechmoc roota na zestaw drobnych, niezależnie przyznawanych przywilejów. Zamiast dawać procesowi pełne uid=0 i wszystkie prawa świata, dorzucasz mu tylko ten jeden kawałek mocy, którego naprawdę potrzebuje — na przykład prawo do nasłuchu na porcie poniżej 1024 albo do zmiany ustawień sieciowych. Reszta uprawnień roota pozostaje poza zasięgiem.

Pod spodem każdy proces ma kilka zestawów capabilities: permitted (co wolno mu w ogóle mieć), effective (co działa w danej chwili) i inheritable (co przejdzie przez execve). Kernel sprawdza je przy operacjach uprzywilejowanych — gdy program chce otworzyć surowe gniazdo czy zmienić właściciela pliku, jądro pyta nie „czy jesteś rootem?”, tylko „czy masz odpowiednią capability?”. Capabilities można też przypiąć do samego pliku binarnego (file capabilities), co jest sprytną alternatywą dla bita SUID.

Przykład z życia

Klasyk: chcesz, żeby serwer WWW albo własna binarka w Node/Go nasłuchiwała na porcie 80, ale nie chcesz uruchamiać jej jako root. Zamiast tego nadajesz jej jedną konkretną zdolność:

  • sudo setcap 'cap_net_bind_service=+ep' /usr/bin/myserver — pozwala binarce bindować niskie porty,
  • getcap /usr/bin/myserver — sprawdza, co faktycznie jest przypięte,
  • setcap -r /usr/bin/myserver — zdejmuje wszystko z powrotem.

Proces startuje jako zwykły użytkownik, łapie port 80 i tyle — żadnego sudo node app.js. Capabilities procesu podejrzysz w /proc//status w polach Cap* albo czytelnie przez getpcaps .

Częste błędy i mity

Po pierwsze, capabilities to nie magiczna piaskownica. Niektóre z nich są tak potężne, że dają praktycznie roota tylnymi drzwiami — sztandarowy przykład to CAP_SYS_ADMIN, nazywana złośliwie „nowym rootem”, bo obejmuje absurdalnie szeroki wachlarz operacji. Dorzucenie jej „bo działało” to nie zasada najmniejszych uprawnień, tylko jej zaprzeczenie.

Po drugie, łatwo pomylić poszczególne capabilities — CAP_NET_BIND_SERVICE (niskie porty) to coś innego niż CAP_NET_RAW (surowe pakiety, np. dla ping) czy CAP_NET_ADMIN (konfiguracja interfejsów). Nadawaj dokładnie tę jedną, której wymaga zadanie. I pamiętaj: setcap bywa wrażliwy na to, czy binarka leży na systemie plików wspierającym rozszerzone atrybuty — na niektórych montażach (np. części overlayfs czy noexec) numer nie przejdzie.

Pojęcia powiązane: bit SUID/SGID, zasada najmniejszych uprawnień (least privilege), seccomp, namespaces i cgroups (fundamenty kontenerów), AppArmor oraz SELinux, a także libcap i komendy setcap, getcap, capsh.