Bezpieczne systemy operacyjne - SELinux -- Security Enhanced Linux: Kontekst bezpieczeństwa procesu i obiektu

Na kontekst bezpieczeństwa procesu składają się: użytkownik który wykonuje proces (a właściwie nazwa użytkownika), rola w jakiej występuje użytkownik oraz jedna z domen tej roli:

Przykładowo po zalogowaniu się do systemu użytkownika pawel, jego proces powłoki (shell) działał będzie w domyślnej roli (user_r ) w domyślnej domenie (user_t). Zatem kontekstem bezpieczeństwa tego procesu będzie:

Do sprawdzenia kontekstu służy polecenie id, wówczas pojawi się m.in. context=uzytkownik:rola:domena. Można też wywołać id -Z, co przyniesie taki skutek, jak na przykładzie poniżej.

pawel@localhost ~ $ id -Z
pawel:user_r:user_t
pawel@localhost ~ $ su
Password:
localhost pawel # id -Z
pawel:user_r:user_t

Przykład ten pokazuje, że pomimo wykonania polecenia su i wprowadzenia poprawnego hasła roota nie zmieniły się ani rola użytkownika, ani domena w tej roli. Tym samym nie zmienił się zakres kompetencji użytkownika i polecenie su nie odniosło zamierzonego skutku. Żeby to zmienić należy użyć polecenia newrole, o ile oczywiście reguły Policy pozwolą na taką zmianę roli, jakiej będziemy chcieli (w tym wypadku jest to zmiana z user_r na sysadm_r).

localhost pawel # newrole -r sysadm_r
Password:
localhost pawel # id -Z
pawel:sysadm_r:sysadm_t

Po wykonaniu polecenia newrole zmienił się kontekst procesu - nową rolą jest sysadm_r, która daje możliwości administrowania systemem, a nową domeną sysadm_t (będąca domyślną domeną sysadm_r).

Jak widać w kontekście bezpieczeństwa procesu istotne znaczenie mają rola i domena. Również obiekty mają swój (pełen) kontekst bezpieczeństwa. W nim kluczowe znaczenie ma typ. Przykładowo dla pliku wykonywalnego klienta IRC (np. Irssi) kontekstem bezpieczeństwa może być:

gdzie ostatnia część tego wyrażenia (irc_exec_t) jest typem pliku. Inne obiekty w systemie także mają swój kontekst bezpieczeństwa np.

Zanim zaczniemy używać systemu z SELinuksem każdy obiekt musi mieć nadany swój kontekst bezpieczeństwa. Ma to miejsce w tzw. procesie etykietowania (labelling), który korzysta z definicji zawartych w pliku file_contexts. Poniżej przykładowe definicje z tego pliku.

/home system_u:object_r:home_root_t
/home/[^/]+ -d system_u:object_r:user_home_dir_t
/home/[^/]+/.+ system_u:object_r:user_home_t

Pierwsza z nich oznacza, że katalog /home otrzyma typ home_root_t. Druga, że katalogi w katalogu /home otrzymają typ user_home_dir_t. Ostatnia natomiast, że wszystkie pliki i katalogi w podkatalogach katalogu /home otrzymają typ user_home_t.

Oczywiście po wykonaniu etykietowania, w trakcie działania systemu, będą mogły powstawać nowe obiekty (np. pliki). W momencie utworzenia otrzymają one typ zgodny z regułami Policy. Typ każdego obiektu nie jest nadany raz na zawsze - może ulec zmianie w wypadkach określonych regułami Policy .

Warto dodać, że wszystkie obiekty o tym samym typie są traktowane jednakowo z punktu widzenia tego, kto i jakie działania może na nich wykonywać oraz jak będzie zachowywał się system w momencie wykonywania tych działań (np. może zostać wymuszona zmiana domeny procesu, który uruchomi plik wykonywalny). Innymi słowy są traktowane tak samo z punktu widzenia Policy.

6. Kontekst bezpieczeństwa procesu i obiektu