W wielu systemach użytkownik root lub superużytkownik ma pełną kontrolę nad systemem. W podsystemie aplikacji systemu UNIX (SUA) nie występuje użytkownik root. Gdy opracowywano standard POSIX, koncepcja użytkownika root została uznana za kwestię administracyjną. W miejsce użytkownika root w standardzie POSIX zdefiniowano odpowiednie uprawnienia do niektórych operacji.

W tym temacie

Mechanizmy setuid oraz setgid

Gdy program jest uruchomiony, mechanizmy setuid oraz setgid umożliwiają wprowadzenie pewnych aspektów podmiotów zabezpieczeń innych niż użytkownik uruchamiający program. Umożliwiają one programowi przełączanie tego aspektu między użytkownikiem uruchamiającym program a innym podmiotem zabezpieczeń.

Osobną kwestię stanowią odpowiednie uprawnienia. Podczas gdy mechanizmy setuid oraz setgid umożliwiają aplikacji określenie odpowiedzi na pytanie „Kim jesteś?”, odpowiednie uprawnienia odpowiadają na pytanie „Co możesz zrobić?”.

Podsystem aplikacji systemu UNIX i tożsamości

W typowych środowiskach systemu UNIX istnieje dokładnie jeden użytkownik, któremu są przyznawane wszystkie uprawnienia. Ten użytkownik, z reguły mający nazwę root, ma identyfikator uid == 0. W podsystemie aplikacji systemu UNIX wszystkie obsługiwane uprawnienia w danym systemie są przydzielane użytkownikom będącym członkami grupy Administratorzy lub Administratorzy domeny w tym systemie. Nie ma potrzeby logowania się jako administrator. Każdy użytkownik będący członkiem grupy Administratorzy lub Administratorzy domeny ma uprawnienia użytkownika root. Nie wszystkie uprawnienia zdefiniowane w systemie POSIX lub UNIX są dostępne w podsystemie SUA. Oznacza to, że istnieją pewne uprawnienia, które nie są przydzielane żadnemu użytkownikowi.

Różnorodne akcje wymagają najczęściej odpowiednich uprawnień. Są to między innymi: dostęp do systemu plików, wysyłanie sygnałów do innych procesów (sterowanie procesami) lub zmiana czynnego identyfikatora użytkownika (UID) lub identyfikatora grupy (GID) procesu w celu zmiany możliwości tego procesu do wykonywania pewnych operacji.

Zgodnie ze standardem POSIX plik ma uprawnienia obejmujące ustawianie bitu identyfikatora UID (setuid) oraz GID (setgid). Jeżeli dla pliku ustawiony jest jeden z tych bitów (lub oba), a proces uruchomi ten plik, wówczas proces uzyskuje identyfikator UID lub GID tego pliku. Ten mechanizm stosowany ostrożnie pozwala użytkownikowi bez uprawnień wykonywać programy działające z wyższymi uprawnieniami właściciela pliku lub grupy. Jednak nieprawidłowe korzystanie z tego mechanizmu może stanowić zagrożenie bezpieczeństwa, gdyż użytkownicy bez uprawnień mogą uzyskać możliwość wykonywania operacji, które powinny być wykonywane wyłącznie przez administratora. Z tego powodu podsystem SUA nie obsługuje domyślnie tego mechanizmu. Jeśli nastąpi próba uruchomienia pliku mającego ustawiony bit setuid lub setgid, wówczas podsystem SUA nie uruchomi pliku i zwróci kod błędu ENOSETUID.

Kwestie instalacji dotyczące mechanizmu setuid w podsystemie aplikacji systemu UNIX

Jeśli użytkownik korzysta z aplikacji wymagającej zachowania zgodnego ze standardem POSIX, można skonfigurować podsystem SUA w taki sposób, aby uruchamiał pliki z ustawionymi bitami setuid lub setgid. Jeśli podsystem SUA zostanie skonfigurowany w taki sposób, to gdy proces uruchomi plik z ustawionym bitem setuid lub setgid, podsystem utworzy dla procesu lokalny token zabezpieczeń z uprawnieniami przypisanymi do właściciela pliku lub grupy. Ze względu na to, że tokeny są lokalne, nie są one rozpoznawane przez inne komputery w sieci. To oznacza na przykład, że nawet jeśli właścicielem pliku jest członek grupy Administratorzy lokalni, proces nie ma zaufanego dostępu za pośrednictwem sieci Microsoft® Windows® do innych komputerów w domenie. Uprawnienia będą obowiązywały jedynie na komputerze, na którym działa proces.

Na przykład proces może uruchomić plik programu z ustawionym bitem setuid należący do członka grupy Administratorzy domeny. Jeśli program podejmie próbę zmiany hasła użytkownika domeny, wówczas taka próba nie powiedzie się, ponieważ tokeny zabezpieczeń są lokalne i nie są rozpoznawane przez inne systemy w domenie. Jeśli jednak program podejmie próbę zmiany lokalnego hasła użytkownika, próba powiedzie się, ponieważ właścicielem pliku jest członek grupy Administratorzy domeny, który na ogół należy do lokalnej grupy Administratorzy komputera. Aby uzyskać informacje na temat konfigurowania podsystemu SUA do uruchamiania plików z ustawionym bitem setuid lub setgid, zobacz pliki Pomocy dostarczone z pakietem Narzędzia i zestaw SDK dla aplikacji systemu UNIX dostępnym do pobrania.

W przypadku funkcji setuid(2), setgid(2) oraz chroot(2) proces musi mieć czynny identyfikator użytkownika mapowany na konto systemowe, konto administratora lokalnej domeny lub konto administratora domeny głównej. Konto administratora lokalnego umożliwia jedynie zmianę identyfikatorów UID lub GID na inny identyfikator w tej samej domenie.

W przypadku funkcji chown(1), chmod(1) oraz chgrp(1) konto musi mieć uprawnienia SE_BACKUP oraz SE_RESTORE systemu Windows, aby wykonywać operacje make na plikach należących do innego użytkownika lub innej grupy i do modyfikowania uprawnień do plików należących do innego użytkownika. Te uprawnienia z reguły należą do kont administratora oraz operatora kopii zapasowych.

Zobacz też