Jak używać SUID, SGID i Sticky Bits w Linuksie

• Dave McKay

  @TheGurkha

• 26 lutego 2020, 8:00am EDT

SUID, SGID, i Sticky Bits to potężne specjalne uprawnienia, które możesz ustawić dla plików wykonywalnych i katalogów w Linuksie. Podzielimy się korzyściami i potencjalnymi pułapkami ich użycia.

They’re Already in Use

Wbudowanie bezpieczeństwa w wieloużytkownikowy system operacyjny stawia kilka dylematów. Weźmy na przykład (pozornie) podstawową koncepcję haseł. Wszystkie one muszą być przechowywane, więc za każdym razem, gdy ktoś się loguje, system może porównać wpisane przez niego hasło z zapisaną kopią. Oczywiście, ponieważ hasła są kluczami do królestwa, muszą być chronione.

W systemie Linux przechowywane hasła są chronione na dwa sposoby: są zaszyfrowane i tylko ktoś z uprawnieniami root może uzyskać dostęp do pliku, który zawiera hasła. Może to brzmi dobrze, ale rodzi pewien dylemat: Jeśli tylko osoby z uprawnieniami root mają dostęp do przechowywanych haseł, to jak ci, którzy nie mają takiego dostępu, mogą zmieniać swoje hasła?

Podniesienie statusu

Zwykle polecenia i programy w systemie Linux są uruchamiane z takim samym zestawem uprawnień jak osoba, która uruchamia program. Gdy root uruchamia polecenie passwd w celu zmiany hasła, działa ono z uprawnieniami root. Oznacza to, że polecenie passwd może swobodnie uzyskać dostęp do haseł przechowywanych w pliku /etc/shadow.

Idealny byłby schemat, w którym każdy w systemie mógłby uruchomić program passwd, ale program passwd zachowałby podwyższone uprawnienia root. To upoważniłoby każdego do zmiany własnego hasła.

Powyższy scenariusz jest dokładnie tym, co robi bit Set User ID (SUID). Uruchamia programy i polecenia z uprawnieniami właściciela pliku, a nie z uprawnieniami osoby, która uruchamia program.

You’re Elevating the Program’s Status

Jest jednak inny dylemat. Osoba ta musi być zabezpieczona przed ingerencją w czyjeś hasło. Linux zawiera schemat SUID, który pozwala uruchamiać aplikacje z zestawem tymczasowo pożyczonych uprawnień, ale to tylko połowa zabezpieczeń.

Mechanizm kontrolny, który zapobiega pracy z hasłem innej osoby, jest zawarty w programie passwd, a nie w systemie operacyjnym i schemacie SUID.

Programy, które działają z podwyższonymi uprawnieniami, mogą stwarzać zagrożenia bezpieczeństwa, jeśli nie są tworzone z myślą o „bezpieczeństwie przez projektowanie”. Oznacza to, że bezpieczeństwo jest pierwszą rzeczą, którą bierzesz pod uwagę, a następnie na tym bazujesz. Nie piszcie programu, a potem próbujcie go zabezpieczyć.

Największą zaletą otwartego oprogramowania jest to, że możecie sami przejrzeć jego kod źródłowy lub odwołać się do zaufanych recenzji. W kodzie źródłowym programu passwd znajdują się kontrole, więc możesz sprawdzić, czy osoba uruchamiająca program jest root. Różne możliwości są dozwolone, jeśli ktoś jest root (lub ktoś używający sudo).

To jest kod, który wykrywa, czy ktoś jest root.

Poniżej znajduje się przykład, w którym jest to brane pod uwagę. Ponieważ root może zmienić dowolne hasło, program nie musi zawracać sobie głowy sprawdzaniem, które hasła zazwyczaj wykonuje, aby sprawdzić, które hasła dana osoba ma uprawnienia do zmiany. Tak więc w przypadku root pomija te kontrole i wychodzi z funkcji sprawdzania.

W przypadku podstawowych poleceń i narzędzi Linuksa możesz być pewien, że mają one wbudowane zabezpieczenia i że kod był wielokrotnie sprawdzany. Oczywiście, zawsze istnieje zagrożenie ze strony nieznanych jeszcze exploitów. Jednakże, łatki lub aktualizacje są szybkie do pojawienia się, aby przeciwdziałać każdej nowo zidentyfikowanej luki.

To jest oprogramowanie stron trzecich – zwłaszcza każdy, który nie jest open-source – trzeba być bardzo ostrożnym o użyciu SUID z. Nie mówimy, żeby tego nie robić, ale jeśli to zrobisz, chcesz się upewnić, że nie narazi to twojego systemu na ryzyko. Nie chcesz podnosić przywilejów programu, który nie będzie prawidłowo zarządzał sobą i osobą go uruchamiającą.

Komendy systemu Linux, które używają SUID

Następujące polecenia systemu Linux, które używają bitu SUID, aby nadać poleceniu podwyższone przywileje, gdy jest ono uruchamiane przez zwykłego użytkownika:

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 oznacza, że bit SUID jest ustawiony.

Uprawnienia do pliku lub katalogu są zwykle reprezentowane przez trzy grupy po trzy znaki: rwx. Oznaczają one read, write i execute. Jeśli litery są obecne, że pozwolenie zostało przyznane. Jeśli jednak zamiast litery występuje myślnik (-), uprawnienie to nie zostało nadane.

Istnieją trzy grupy tych uprawnień (od lewej do prawej): dla właściciela pliku, dla członków grupy pliku i dla innych. Gdy bit SUID jest ustawiony na pliku, litera „s” reprezentuje uprawnienie execute właściciela.

Jeśli bit SUID jest ustawiony na pliku, który nie ma możliwości wykonywania, wielka litera „S” oznacza to.

Przyjrzymy się przykładowi. Zwykły użytkownik dave wpisuje komendę passwd:

passwd

Komenda passwd prosi dave o podanie nowego hasła. Możemy użyć polecenia ps, aby zobaczyć szczegóły uruchomionych procesów.

Wykorzystamy ps z grep w innym oknie terminala i poszukamy procesu passwd. Użyjemy również opcji -e (każdy proces) i -f (pełny format) z ps.

Wpisujemy następujące polecenie:

ps -e -f | grep passwd

Zgłaszane są dwa wiersze, z których drugi to proces grep szukający poleceń zawierających ciąg „passwd”. Nas jednak interesuje pierwsza linia, ponieważ jest to linia dla procesu passwd, który został uruchomiony przez dave.

Widzimy, że proces passwd działa tak samo, jak gdyby root go uruchomił.

Ustawianie bitu SUID

Bit SUID można łatwo zmienić za pomocą chmod. Tryb symboliczny u+s ustawia bit SUID, a tryb symboliczny u-s czyści bit SUID.

Aby zilustrować niektóre z koncepcji bitu SUID, stworzyliśmy mały program o nazwie htg. Znajduje się on w katalogu głównym użytkownika dave i nie ma ustawionego bitu SUID. Kiedy jest on wykonywany, wyświetla rzeczywiste i efektywne identyfikatory użytkownika (UID).

Rzeczywisty UID należy do osoby, która uruchomiła program. Efektywny identyfikator to konto, przy którym program zachowuje się tak, jakby został uruchomiony przez osobę, która go uruchomiła.

Wpisujemy następujące polecenie:

ls -lh htg

./htg

Po uruchomieniu lokalnej kopii programu widzimy, że rzeczywisty i efektywny identyfikator są ustawione na dave. Zachowuje się więc tak, jak powinien zachowywać się normalny program.

Skopiujmy go do katalogu /usr/local/bin, aby inni mogli go używać.

Wpisujemy następujące polecenie, używając chmod do ustawienia bitu SUID, a następnie sprawdzamy, czy został on ustawiony:

sudo cp htg /usr/local/bin

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

ls -hl /usr/local/bin/htg

Więc program został skopiowany, a bit SUID ustawiony. Uruchomimy go ponownie, ale tym razem uruchomimy kopię w folderze /usr/local/bin:

htg

Mimo że dave uruchomił program, efektywny identyfikator jest ustawiony na użytkownika root. Jeśli więc mary uruchomi program, stanie się to samo, jak pokazano poniżej:

htg

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

RELATED: How to Use the chmod Command on Linux

The SGID Bit

Bit Set Group ID (SGID) jest bardzo podobny do bitu SUID. Kiedy bit SGID jest ustawiony na pliku wykonywalnym, efektywna grupa jest ustawiona 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 tak, aby pokazywał również grupę efektywną. Zmienimy grupę programu htg na grupę domyślną użytkownika mary, czyli mary. Użyjemy również trybów symbolicznych u-s i g+s z chown, aby usunąć bit SUID i ustawić SGID.

W tym celu wpiszemy następujące 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

Widzimy bit SGID oznaczony przez „s” w uprawnieniach grupy. Zauważ też, że grupa jest ustawiona na mary, a nazwa pliku jest teraz podświetlona na żółto.

Zanim uruchomimy program, ustalmy, do jakich grup należą dave i mary. Użyjemy polecenia id z opcją -G (groups), aby wypisać wszystkie identyfikatory grup. Następnie uruchomimy program htg jako dave.

Wpiszemy następujące polecenia:

id -G dave

id -G mary

htg

Identyfikatorem grupy domyślnej dla mary jest 1001, a grupą efektywną programu htg jest 1001. Tak więc, mimo że został on uruchomiony przez dave, działa z uprawnieniami członków grupy mary. To tak samo, jak gdyby dave dołączył do grupy mary.

Zastosujmy bit SGID do katalogu. Najpierw utworzymy katalog o nazwie „work”, a następnie zmienimy jego grupę na „geek”. Następnie ustawimy bit SGID na tym katalogu.

Kiedy użyjemy ls do sprawdzenia ustawień katalogu, użyjemy również opcji -d (katalog), aby zobaczyć szczegóły katalogu, a nie jego zawartość.

Wpisujemy następujące polecenia:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

Ustawiono bit SGID i grupę „geek”. Będą one miały wpływ na wszelkie elementy utworzone wewnątrz katalogu work.

Wpisujemy następujące polecenie, aby wejść do katalogu work, utworzyć katalog o nazwie „demo” i sprawdzić jego właściwości:

cd work

mkdir demo

ls -lh -d demo

Bit SGID i grupa „geek” są automatycznie stosowane do katalogu „demo”.

Następnie wpiszmy następujące polecenie, aby utworzyć plik za pomocą polecenia touch i sprawdzić jego właściwości:

touch useful.sh

ls -lh useful.sh

Grupa nowego pliku jest automatycznie ustawiana na „geek.”

PORÓWNANIE: How to Use the chown Command on Linux

The Sticky Bit

Kleisty bit dostaje swoją nazwę od swojego historycznego przeznaczenia. Gdy był ustawiony w pliku wykonywalnym, sygnalizował systemowi operacyjnemu, że tekstowe części pliku powinny być przechowywane w swapie, dzięki czemu ich ponowne użycie było szybsze. W Linuksie, lepki bit wpływa tylko na katalog – ustawienie go na pliku nie miałoby sensu.

Kiedy ustawisz lepki bit na katalogu, ludzie mogą usuwać tylko pliki, które należą do nich w tym katalogu. Nie mogą usuwać plików, które należą do kogoś innego, bez względu na to, jaka kombinacja uprawnień do plików jest ustawiona na plikach.

To pozwala na stworzenie katalogu, który każdy i procesy, które uruchamiają – może używać jako wspólny magazyn plików. Pliki są chronione, ponieważ, ponownie, nikt nie może usunąć cudzych plików.

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

Wpisujemy 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śli bit lepki jest ustawiony, bit wykonywalny „innego” zestawu uprawnień do plików jest ustawiony na „t”. Nazwa pliku jest również podświetlona na niebiesko.

Foldery /tmp i /var/tmp są dwoma przykładami katalogów, które mają ustawione wszystkie uprawnienia do plików dla właściciela, grupy i innych (dlatego są podświetlone na zielono). Są one używane jako współdzielone lokalizacje dla plików tymczasowych.

Z tymi uprawnieniami każdy powinien, teoretycznie, być w stanie zrobić wszystko. Jednak bit sticky je unieważnia i nikt nie może usunąć pliku, który nie należy do niego.

Przypomnienia

Poniżej znajduje się krótka lista kontrolna tego, co omówiliśmy powyżej, do wykorzystania w przyszłości:

• SUID działa tylko na plikach.
• Możesz zastosować SGID do katalogów i plików.
• Możesz zastosować bit lepki tylko do katalogów.
• Jeśli wskaźniki „s„, „g” lub „t” są pisane wielkimi literami, bit wykonywalny (x) nie został ustawiony.