SUID, SGID i Sticky Bits to potężne specjalne uprawnienia, które można ustawić dla plików wykonywalnych i katalogów w systemie Linux. Podzielimy się korzyściami – i potencjalnymi pułapkami – korzystania z nich.
Spis treści:
Są już w użyciu
Wbudowanie zabezpieczeń w system operacyjny dla wielu użytkowników wiąże się z kilkoma problemami. Weźmy na przykład (pozornie) podstawową koncepcję haseł. Wszystkie muszą być przechowywane, aby za każdym razem, gdy ktoś się logował, system mógł porównać wpisane przez niego hasło z zapisaną kopią. Oczywiście, ponieważ hasła są kluczami do królestwa, należy je chronić.
W systemie Linux przechowywane hasła są chronione na dwa sposoby: są szyfrowane i tylko osoba z uprawnieniami administratora może uzyskać dostęp do pliku zawierającego hasła. To może brzmieć dobrze, ale stanowi dylemat: jeśli tylko osoby z uprawnieniami roota mogą uzyskać dostęp do przechowywanych haseł, w jaki sposób osoby, które nie mają tego dostępu, mogą zmienić swoje hasła?
Podnoszenie swojego statusu
Zwykle polecenia i programy systemu Linux działają z tym samym zestawem uprawnień, co osoba, która uruchamia program. Kiedy root wykonuje polecenie passwd zmienić hasło, działa z uprawnieniami roota. Oznacza to, że polecenie passwd może swobodnie uzyskiwać 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 roota. Umożliwiłoby to każdemu zmianę własnego hasła.
Powyższy scenariusz jest dokładnie tym, co robi bit Set User ID (SUID). To uruchamia programy i polecenia z uprawnieniami właściciela pliku, a nie z uprawnieniami osoby, która uruchamia program.
Podnosisz status programu
Jest jednak inny dylemat. Należy uniemożliwić tej osobie ingerowanie w hasło innej osoby. Linux zawiera schemat SUID, który pozwala mu uruchamiać aplikacje z zestawem tymczasowo pożyczonych uprawnień – ale to tylko połowa historii bezpieczeństwa.
Mechanizm kontroli, który uniemożliwia komuś pracę 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ą stanowić zagrożenie dla bezpieczeństwa, jeśli nie są tworzone z myślą o bezpieczeństwie według projektu. Oznacza to, że bezpieczeństwo jest pierwszą rzeczą, którą bierzesz pod uwagę, a następnie na tym budujesz. Nie pisz swojego programu, a potem spróbuj go zabezpieczyć.
Największą zaletą oprogramowania open source jest możesz sam spojrzeć na kod źródłowy lub zapoznaj się z zaufanymi recenzjami. W kodzie źródłowym programu passwd znajdują się kontrole, dzięki czemu można sprawdzić, czy osoba uruchamiająca program jest rootem. Dozwolone są różne możliwości, jeśli ktoś jest rootem (lub ktoś używa sudo).
To to kod, który wykrywa, czy ktoś jest rootem.
Poniższy przykład jest brany pod uwagę. Ponieważ root może zmienić dowolne hasło, program nie musi zawracać sobie głowy sprawdzaniem, które zwykle przeprowadza, aby zobaczyć, które hasła osoba ma zmiany uprawnień. Więc dla roota, to pomija te sprawdzenia i zamyka funkcję sprawdzania.
Dzięki podstawowym poleceniom i narzędziom Linuksa możesz mieć pewność, że mają wbudowane zabezpieczenia i że kod był wielokrotnie sprawdzany. Oczywiście zawsze istnieje zagrożenie nieznanymi jeszcze exploitami. Jednak łatki lub aktualizacje szybko wydają się przeciwdziałać wszelkim nowo zidentyfikowanym lukom.
Jest to oprogramowanie innej firmy – zwłaszcza takie, które nie jest oprogramowaniem typu open source – z którym należy zachować szczególną ostrożność podczas używania SUID. Nie mówimy, że nie rób tego, ale jeśli to zrobisz, chcesz mieć pewność, że nie narazi to systemu na ryzyko. Nie chcesz podnosić uprawnień programu, który nie będzie prawidłowo samozarządzać sobą i osobą, która go prowadzi.
Polecenia systemu Linux używające SUID
Poniżej przedstawiono kilka poleceń systemu Linux, które używają bitu SUID, aby nadać poleceniu podwyższone uprawnienia, gdy jest 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
Zwróć uwagę, że nazwy plików są podświetlone na czerwono, co wskazuje, że bit SUID jest ustawiony.
Uprawnienia do pliku lub katalogu są zwykle reprezentowane przez trzy grupy po trzy znaki: rwx. Oznaczają one odczyt, zapis i wykonanie. Jeśli listy są obecne, to zezwolenie zostało udzielone. Jeśli jednak zamiast litery występuje myślnik (-), to zezwolenie nie zostało udzielone.
Istnieją trzy grupy tych uprawnień (od lewej do prawej): uprawnienia właściciela pliku, członków grupy pliku i innych. Gdy bit SUID jest ustawiony w pliku, litera „s” oznacza uprawnienia właściciela do wykonywania.
Jeśli bit SUID jest ustawiony w pliku, który nie ma możliwości wykonywania, oznacza to wielką literę „S”.
Spójrzmy na przykład. Zwykły użytkownik Dave wpisuje polecenie passwd:
passwd
Polecenie passwd prosi Dave’a o podanie nowego hasła. Możemy użyć polecenia ps aby zobaczyć szczegóły uruchomionych procesów.
Będziemy używać ps z grep w innym oknie terminala i poszukaj procesu passwd. Użyjemy również opcji -e (każdy proces) i -f (pełny format) w ps.
Wpisujemy następujące polecenie:
ps -e -f | grep passwd
Zgłaszane są dwie linie, z których druga to proces grep szukający poleceń zawierających ciąg „passwd”. Jest to jednak pierwsza linia, która nas interesuje, ponieważ jest to ta dotycząca procesu passwd uruchomionego przez Dave’a.
Widzimy, że proces passwd działa tak samo, jak gdyby uruchomił go root.
Ustawianie bitu SUID
Łatwo jest zmienić bit SUID za pomocą chmod. Tryb symboliczny u + s ustawia bit SUID, a tryb symboliczny usa czyści bit SUID.
Aby zilustrować niektóre koncepcje bitu SUID, stworzyliśmy mały program o nazwie htg. Znajduje się w katalogu głównym użytkownika dave i nie ma ustawionego bitu SUID. Po uruchomieniu wyświetla rzeczywiste i skuteczne identyfikatory użytkowników (UID).
Prawdziwy UID należy do osoby, która uruchomiła program. Efektywny identyfikator to konto, na którym program zachowuje się tak, jakby został uruchomiony.
Wpisujemy:
ls -lh htg
./htg
Kiedy uruchamiamy lokalną kopię programu, widzimy, że zarówno prawdziwe, jak i skuteczne identyfikatory są ustawione na dave. Tak więc zachowuje się tak, jak powinien normalny program.
Skopiujmy go do katalogu / usr / local / bin, aby inni mogli z niego korzystać.
Wpisujemy następujące polecenie, używając chmod, aby ustawić bit SUID, a następnie sprawdzamy, czy został ustawiony:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Tak więc program jest kopiowany i ustawiany jest bit SUID. 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. Więc jeśli mary uruchomi program, dzieje się to samo, co pokazano poniżej:
htg
Prawdziwym identyfikatorem jest mary, a efektywnym identyfikatorem jest root. Program działa z uprawnieniami użytkownika root.
Bit SGID
Bit Set Group ID (SGID) jest bardzo podobny do bitu SUID. Gdy bit SGID jest ustawiony 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, mary. Użyjemy również trybów symbolicznych us i g + s z chown, aby usunąć bit SUID i ustawić SGID.
Aby to zrobić, wpisujemy:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Możesz zobaczyć bit SGID oznaczony przez „s” w uprawnieniach grupy. Zwróć również uwagę, że grupa jest ustawiona na mary, a nazwa pliku jest teraz podświetlona na żółto.
Zanim uruchomimy program, ustalmy, do których grup należą dave i mary. Użyjemy polecenia id z opcją -G (grupy), wydrukować wszystkie identyfikatory grup. Następnie uruchomimy program htg jako dave.
Wpisujemy następujące polecenia:
id -G dave
id -G mary
htg
Identyfikator domyślnej grupy dla mary to 1001, a efektywna grupa programu htg to 1001. Tak więc, mimo że został uruchomiony przez dave’a, działa z uprawnieniami członków grupy mary. To tak, jakby Dave dołączył do grupy mary.
Zastosujmy bit SGID do katalogu. Najpierw utworzymy katalog o nazwie „praca”, a następnie zmienimy jego grupę na „geek”. Następnie ustawimy bit SGID w katalogu.
Kiedy używamy 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
Bit SGID i grupa „geek” są ustawione. Wpłynie to na wszystkie elementy utworzone w katalogu roboczym.
Wpisujemy następujące polecenie, aby wejść do katalogu roboczego, 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”.
Wpiszmy następujące polecenie, aby utworzyć plik z rozszerzeniem dotknąć polecenie i sprawdź jego właściwości:
touch useful.sh
ls -lh useful.sh
Grupa nowego pliku jest automatycznie ustawiana na „geek”.
Lepki kawałek
Wędzidło lepkie zawdzięcza swoją nazwę przeznaczeniu historycznemu. Po ustawieniu na plik wykonywalny sygnalizował systemowi operacyjnemu, że części tekstowe pliku wykonywalnego powinny być przechowywane w zamian, co przyspiesza ich ponowne użycie. W Linuksie bit „sticky” wpływa tylko na katalog – ustawienie go w pliku nie miałoby sensu.
Gdy ustawisz „sticky bit” w katalogu, ludzie będą mogli usuwać tylko te pliki, które należą do nich w tym katalogu. Nie mogą usuwać plików należących do kogoś innego, bez względu na kombinację uprawnień do plików ustawioną dla tych plików.
Pozwala to na utworzenie katalogu, którego wszyscy – i uruchamiane przez nich procesy – mogą używać jako współdzielonego magazynu plików. Pliki są chronione, ponieważ znowu nikt nie może usuwać plików innych osób.
Utwórzmy katalog o nazwie „shared”. Użyjemy trybu symbolicznego o + t z chmod, aby ustawić bit lepki w tym katalogu. Następnie przyjrzymy się uprawnieniom w tym katalogu, a także katalogom / 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 ustawiany na „t”. Nazwa pliku jest również podświetlona na niebiesko.
Foldery / tmp i / var / tmp to dwa przykłady katalogów, które mają wszystkie uprawnienia do plików ustawione dla właściciela, grupy i innych osób (dlatego są podświetlone na zielono). Są używane jako współdzielone lokalizacje dla plików tymczasowych.
Mając te uprawnienia, teoretycznie każdy powinien być w stanie zrobić wszystko. Jednak lepki bit zastępuje je 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 w przypadku plików.
Możesz zastosować SGID do katalogów i plików.
Możesz zastosować tylko lepki bit do katalogów.
Jeśli wskaźniki „s”, „g” lub „t” pojawiają się wielkimi literami, to wykonywalny bit (x) nie został ustawiony.