Jak korzystać z SUID, SGID i Sticky Bits w systemie Linux

SUID, SGID oraz Sticky Bits to specjalne uprawnienia, które można przypisać plikom wykonywalnym i katalogom w systemie Linux. W tym artykule omówimy korzyści i możliwe zagrożenia związane z ich używaniem.

Zastosowanie w praktyce

Implementacja zabezpieczeń w systemach wieloużytkownikowych wiąże się z wieloma wyzwaniami. Weźmy na przykład podstawową koncepcję haseł. Wszystkie hasła muszą być przechowywane, aby system mógł porównać wprowadzone dane z zapisanymi danymi podczas logowania. Oczywiście, ponieważ hasła są kluczowe dla bezpieczeństwa, muszą być odpowiednio chronione.

W systemie Linux przechowywane hasła są zabezpieczone na dwa sposoby: są szyfrowane, a dostęp do pliku z hasłami mają tylko użytkownicy z uprawnieniami administratora. Mimo że brzmi to dobrze, rodzi to pytanie: jak osoby bez dostępu do roota mogą zmienić swoje hasła?

Podnoszenie uprawnień

Standardowo polecenia i programy w systemie Linux działają z tymi samymi uprawnieniami, co użytkownik, który je uruchamia. Na przykład, gdy użytkownik root wykonuje polecenie passwd, działa on z uprawnieniami roota, co pozwala mu na dostęp do haseł w pliku /etc/shadow.

Optymalnym rozwiązaniem byłoby umożliwienie każdemu użytkownikowi wywołania programu passwd, który zachowałby podwyższone uprawnienia roota, co pozwoliłoby użytkownikom na zmianę własnych haseł.

To właśnie umożliwia bit Set User ID (SUID). Funkcjonuje on w taki sposób, że programy i polecenia są uruchamiane z uprawnieniami właściciela pliku, a nie osoby, która je uruchamia.

Zarządzanie uprawnieniami

Kolejnym dylematem jest zapewnienie, aby użytkownik nie miał możliwości modyfikacji haseł innych osób. Linux posiada mechanizm SUID, który pozwala na uruchamianie aplikacji z tymczasowo pożyczonymi uprawnieniami, ale to tylko część systemu zabezpieczeń.

Kontrola, która uniemożliwia użytkownikowi zmianę haseł innych, jest implementowana w programie passwd, a nie w systemie operacyjnym lub schemacie SUID.

Programy działające z podwyższonymi uprawnieniami mogą stanowić zagrożenie dla bezpieczeństwa, jeśli nie są zaprojektowane z uwzględnieniem zasad bezpieczeństwa. Oznacza to, że bezpieczeństwo powinno być priorytetem w procesie tworzenia, a nie dodatkiem po fakcie.

Jedną z największych zalet oprogramowania open source jest to, że możesz samodzielnie przeanalizować kod źródłowy lub zapoznać się z recenzjami. Kod źródłowy programu passwd zawiera kontrole, które weryfikują, czy osoba uruchamiająca program ma uprawnienia roota. W przypadku roota dostępne są różne możliwości.

Ten fragment kodu odpowiada za wykrywanie, czy użytkownik jest rootem.

W przypadku roota, program nie musi przeprowadzać standardowych weryfikacji, ponieważ ma pełny dostęp do zarządzania hasłami. Dlatego dla roota pomija te kontrole i wyłącza funkcję sprawdzania.

Dzięki podstawowym poleceniom i narzędziom w systemie Linux można być pewnym, że zawierają one wbudowane zabezpieczenia oraz zostały wielokrotnie sprawdzone. Oczywiście zawsze istnieje ryzyko związane z nieznanymi exploitami. Jednak patche i aktualizacje są szybko wprowadzane, aby zniwelować nowo odkryte luki.

Szczególną ostrożność należy zachować przy używaniu SUID w przypadku oprogramowania innych firm, szczególnie gdy nie jest ono open source. Nie oznacza to, że należy całkowicie unikać tego rozwiązania, ale warto upewnić się, że nie narazi się systemu na niebezpieczeństwo. Należy unikać podnoszenia uprawnień programu, który nie jest wystarczająco bezpieczny i nie potrafi odpowiednio zarządzać swoimi uprawnieniami.

Polecenia systemu Linux korzystające z SUID

Poniżej przedstawiamy kilka poleceń systemu Linux, które wykorzystują bit SUID do uzyskania podwyższonych uprawnień podczas uruchamiania przez zwykłych użytkowników:

ls -l /bin/su

ls -l /bin/ping

ls -l /bin/mount

ls -l /bin/umount

ls -l /usr/bin/passwd

Zauważ, że nazwy plików są wyróżnione na czerwono, co wskazuje, że bit SUID jest aktywny.

Uprawnienia do pliku lub katalogu są zazwyczaj przedstawiane w formie trzech grup po trzy znaki: rwx, co oznacza odpowiednio odczyt, zapis i wykonanie. Obecność liter wskazuje na przyznanie uprawnienia, podczas gdy myślnik (-) oznacza brak uprawnienia.

Trzy grupy uprawnień (od lewej do prawej) to uprawnienia właściciela pliku, członków grupy pliku oraz innych. Gdy bit SUID jest ustawiony, litera „s” zastępuje literę „x” w uprawnieniach właściciela.

Jeśli bit SUID jest aktywny w pliku, który nie ma ustawionego uprawnienia do wykonywania, to pojawi się wielka litera „S”.

Rozważmy przykład, w którym użytkownik Dave wykonuje polecenie passwd:

passwd

Polecenie passwd prosi Dave’a o podanie nowego hasła. Możemy użyć polecenia ps do wyświetlenia szczegółów uruchomionych procesów.

Wykorzystamy ps w połączeniu z grep w innym terminalu, aby znaleźć proces passwd. Użyjemy opcji -e (wszystkie procesy) oraz -f (pełny format) w ps.

Wprowadzamy następujące polecenie:

ps -e -f | grep passwd

Widocznych jest dwie linie, z których druga dotyczy procesu grep poszukującego poleceń zawierających „passwd”. Nas interesuje jednak pierwsza linia, dotycząca procesu passwd uruchomionego przez Dave’a.

Widzimy, że proces passwd działa z uprawnieniami roota, mimo że został uruchomiony przez użytkownika Dave.

Ustawianie bitu SUID

Ustawienie bitu SUID jest proste i można to zrobić za pomocą polecenia chmod. Tryb symboliczny u+s ustawia bit SUID, a usa usuwa ten bit.

Aby zobrazować koncepcje bitu SUID, stworzyliśmy prosty program o nazwie htg, który znajduje się w katalogu domowym użytkownika dave i nie ma ustawionego bitu SUID. Po uruchomieniu wyświetla rzeczywiste i efektywne identyfikatory użytkowników (UID).

Prawdziwy UID należy do osoby, która uruchomiła program, natomiast efektywny UID to konto, na którym program działa.

Wykonujemy następujące polecenia:

ls -lh htg

./htg

Gdy uruchamiamy lokalną wersję programu, zarówno prawdziwy, jak i efektywny identyfikator użytkownika są ustawione na dave, co jest normalnym zachowaniem programu.

Kopiujemy program do katalogu /usr/local/bin, aby był dostępny dla innych użytkowników.

Wprowadzamy poniższe polecenia, używając chmod do ustawienia bitu SUID, a następnie sprawdzamy, czy został aktywowany:

sudo cp htg /usr/local/bin

sudo chmod u+s /usr/local/bin/htg

ls -hl /usr/local/bin/htg

Program został skopiowany, a bit SUID ustawiony. Teraz uruchomimy go ponownie, tym razem z katalogu /usr/local/bin:

htg

Pomimo że program został uruchomiony przez Dave’a, efektywny identyfikator jest ustawiony na root. Jeśli Mary również uruchomi program, sytuacja będzie analogiczna:

htg

Prawdziwy identyfikator to Mary, a efektywny identyfikator to root. Program działa z uprawnieniami użytkownika root.

Bit SGID

Bit Set Group ID (SGID) działa podobnie do bitu SUID. Gdy bit SGID jest aktywowany w pliku wykonywalnym, efektywna grupa jest ustawiana na grupę pliku. Proces działa z uprawnieniami członków grupy pliku, a nie z uprawnieniami osoby, która go uruchomiła.

Poprawiliśmy nasz program htg, aby pokazywał również efektywną grupę. Zmienimy grupę programu htg na domyślną grupę użytkownika Mary, czyli mary. Użyjemy także trybów symbolicznych us i g + s z chown, aby usunąć bit SUID i ustawić SGID.

Aby to zrobić, wprowadzamy kolejne polecenia:

sudo chown root:mary /usr/local/bin/htg

sudo chmod u-s,g+s /usr/local/bin/htg

ls -lh /usr/local/bin/htg

Bit SGID jest oznaczony przez „s” w uprawnieniach grupy. Zauważ również, że grupa została zmieniona na mary, a nazwa pliku jest teraz podświetlona na żółto.

Zanim uruchomimy program, sprawdźmy, do jakich grup należą użytkownicy Dave i Mary. Wykorzystamy polecenie id z opcją -G (grupy), aby wydrukować wszystkie identyfikatory grup. Następnie uruchomimy program htg jako Dave.

Wprowadzamy następujące polecenia:

id -G dave

id -G mary

htg

Identyfikator domyślnej grupy dla Mary to 1001, a efektywna grupa programu htg również wynosi 1001. Tak więc, mimo że program został uruchomiony przez Dave’a, działa z uprawnieniami członków grupy Mary. To tak, jakby Dave dołączył do grupy Mary.

Przyjrzyjmy się teraz bitowi SGID w kontekście katalogów. Najpierw stworzymy katalog o nazwie „work”, a następnie zmienimy jego grupę na „geek”. Następnie ustawimy bit SGID dla tego katalogu.

Używając polecenia ls z opcją -d (katalog), aby zobaczyć szczegóły katalogu, a nie jego zawartość, wprowadzamy następujące polecenia:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

Bit SGID oraz grupa „geek” zostały aktywowane. To ustawienie wpłynie na wszystkie pliki utworzone w katalogu roboczym.

Wprowadzamy następnie polecenie, aby przejść do katalogu roboczego, utworzyć podkatalog „demo” i sprawdzić jego właściwości:

cd work

mkdir demo

ls -lh -d demo

Bit SGID oraz grupa „geek” automatycznie przypisane do katalogu „demo”.

Wprowadźmy polecenie do utworzenia pliku z użyciem polecenia touch i sprawdźmy jego atrybuty:

touch useful.sh

ls -lh useful.sh

Grupa nowego pliku jest automatycznie ustawiana na „geek”.

Sticky Bit

Sticky Bit ma swoją nazwę ze względu na historyczne zastosowanie. Kiedy był ustawiany na pliku wykonywalnym, informował system operacyjny, że części tekstowe pliku wykonywalnego powinny być przechowywane, co przyspieszało ich ponowne użycie. W systemie Linux bit „sticky” dotyczy jedynie katalogów – jego ustawienie na pliku nie ma sensu.

Ustawienie „sticky bit” w katalogu umożliwia użytkownikom usuwanie tylko tych plików, które do nich należą. Nie mają oni możliwości usuwania plików innych użytkowników, niezależnie od przyznanych im uprawnień.

Taki mechanizm pozwala na stworzenie katalogu, który może być współdzielony przez wszystkich użytkowników, a pliki w nim są chronione, ponieważ nikt nie ma możliwości usunięcia plików innych osób.

Stwórzmy katalog o nazwie „shared”. Użyjemy trybu symbolicznego o+t z chmod, aby aktywować bit sticky w tym katalogu. Następnie przyjrzymy się uprawnieniom w tym katalogu oraz w katalogach /tmp i /var/tmp.

Wprowadzamy następujące polecenia:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

Jeżeli bit sticky jest ustawiony, bit wykonywalny dla innych użytkowników będzie oznaczony literą „t”, a nazwa pliku zostanie podświetlona na niebiesko.

Katalogi /tmp i /var/tmp to przykłady lokalizacji, gdzie wszystkie uprawnienia są ustawione dla właściciela, grupy i innych użytkowników (dlatego są podświetlone na zielono). Służą one jako współdzielone lokalizacje dla plików tymczasowych.

Teoretycznie każdy użytkownik powinien mieć pełne prawa do działania w tych katalogach. Niemniej jednak bit sticky ogranicza te uprawnienia, uniemożliwiając usunięcie pliku, który nie należy do danego użytkownika.

Podsumowanie

Poniżej znajduje się krótka lista kontrolna dotycząca omawianych wcześniej zagadnień, która może być przydatna w przyszłości:

– SUID działa tylko w przypadku plików.
– Można przypisać SGID zarówno do plików, jak i katalogów.
– Sticky bit można zastosować jedynie do katalogów.
– Jeśli wskaźniki „s”, „g” lub „t” są zapisane wielką literą, oznacza to, że bit wykonywalny (x) nie został aktywowany.