System w kamizelce

Systemy operacyjne określane mianem trusted różnią się od zwykłych systemów m.in. podejściem do kwestii przydzielania i realizacji przywilejów oraz klasyfikacją zasobów.

Systemy operacyjne określane mianem trusted różnią się od zwykłych systemów m.in. podejściem do kwestii przydzielania i realizacji przywilejów oraz klasyfikacją zasobów.

W typowych serwerowych systemach operacyjnych, jak Unix, Linux, Windows (NT i nowsze), a nawet VMS, system uprawnień do wykonywania pewnych operacji czy dostępu do zasobów jest mniej lub bardziej dobrowolny.

Podstawą zabezpieczeń jest w nich podział poszczególnych zadań na procesy działające z różnymi przywilejami (z reguły przypisanymi pewnym użytkownikom). Do tego dochodzą uprawnienia wbudowane w system plików, w którym każdy plik ma swojego właściciela, który z kolei może decydować o zakresie uprawnień do tego pliku możliwym do przyznania innym użytkownikom.

Bez dyktatury bezpieczniej

Tym, co łączy "zwykłe" systemy, jest obecność jednego użytkownika o rozszerzonych uprawnieniach. W systemach Unix/Linux jest to użytkownik o nazwie root, zaś w Windows - użytkownik z uprawnieniami administracyjnymi. W obu przypadkach użytkownik ten praktycznie "może wszystko". Może np. uzyskiwać dostęp do plików z pominięciem mechanizmu praw dostępu, zmieniać ustawienia właściciela pliku, wyłączać procesy innych użytkowników itd. Ma także wiele innych uprawnień, które, gdy uzyska je osoba niepowołana, mogą mieć katastrofalne skutki.

W systemach typu trusted nie ma takiej dowolności. Co więcej, w ogóle nie ma w nich owego wszechwładnego użytkownika. Dostęp do pliku jest w nich rozpatrywany zawsze w kategoriach elementów aktywnych - obiektów (objects) - oraz pozostających z nimi w pewnej relacji elementów pasywnych - podmiotów (subjects). Obiektem może być proces lub użytkownik, a podmiotem - plik lub urządzenie.

System typu trusted ściśle kontroluje relacje między obiektami a podmiotami. Każdy obiekt posiada przypisany zbiór czynności, które może wykonywać w stosunku do danego podmiotu, takich jak odczyt, zapis, uruchamianie czy bardziej specyficzne dla poszczególnych systemów operacyjnych - dowiązywanie, kasowanie, odczytanie statusu, wysłanie sygnału itd.

Z klauzulą tajności

Przynajmniej w części systemów typu trusted istnieje możliwość przypisywania obiektom poziomu bezpieczeństwa. Mechanizm ten można porównać do klasyfikacji tajności informacji. Tak jak osoba, która w zależności od przebytej weryfikacji może być dopuszczana do dokumentów opatrzonych określoną klauzulą: jawne, poufne, tajne czy ściśle tajne, system uniemożliwia wykonywanie operacji niemieszczących się w pewnym profilu.

W takich systemach obiekt operujący na umownym poziomie "tajne" może odczytać informacje jawne lub poufne. Z kolei obiekt działający na jednym z tych poziomów nie może uzyskać dostępu do informacji opatrzonych klauzulą wyższego rzędu. Nie jest jednak tak, że obiekt "tajny" w stosunku do obiektów/podmiotów niższej klasy zachowuje się dowolnie. Nie może np. zapisać informacji ze swojego poziomu do podmiotów (np. plików) z klauzulą niższą. Obowiązuje tu zasada, że nie może być przepływu informacji z góry, tj. z wyższych poziomów zaufania w dół, czyli do poziomów klasyfikowanych niżej.

Mogę tyle, ile muszę

Kolejnym ważnym mechanizmem systemów "wzmocnionych" pod względem bezpieczeństwa jest ścisła i, co ważne, obowiązkowa separacja procesów użytkowników od procesów systemu operacyjnego, a także poszczególnych procesów od siebie nawzajem. Każdy proces działa w ściśle izolowanym środowisku, w którym posiada dostęp tylko do tych zasobów, które są mu niezbędne do poprawnego wykonywania przewidzianych zadań. Pozostałe zasoby są dla niego niedostępne.

Separacja ma ogromne znaczenie dla bezpieczeństwa systemu operacyjnego. Większość ataków hakerskich na serwery polega na wykorzystaniu błędu programisty w konkretnej aplikacji czy usłudze do tego, by móc wykonać w systemie działanie, do którego formalnie nie ma się uprawnień. Celem ataku może być także rozszerzenie uprawnień już dostępnych. W szczególności atakujący dążą do uzyskania możliwości wykonania w systemie własnego kodu z jak najszerszymi uprawnieniami, a stąd już tylko krok do uzyskania całkowitej kontroli nad systemem. Jeśli aplikacja działa z uprawnieniami użytkownika uprzywilejowanego, jest to zarazem krok ostatni...

Systemy trusted dostępne czy to komercyjnie, czy też jako rozwiązania open source rzadko przechodzą pełny audyt kodu źródłowego, który jest utożsamiany z wysokim bezpieczeństwem. Skoro tak, to w zdecydowanej większości systemów istnieją aplikacje lub usługi, w których wcześniej czy później da się znaleźć błędy mogące stanowić furtkę dla włamywacza. Mimo to ścisła separacja uprawnień oraz kontrola dostępu do zasobów są dla atakującego bardzo poważnymi utrudnieniami.

Co znaczą uprawnienia

W "zwykłych" systemach, takich jak Windows czy Unix, każda aplikacja działająca z przywilejami zwykłego użytkownika ma prawo wykonać praktycznie każdy zainstalowany program dopóty, dopóki jej tego nie zabronimy, zmieniając odpowiednie uprawnienia. Użytkownik będący właścicielem pliku może dowolnie zmieniać dotyczące go uprawnienia, w tym np. atrybuty związane z przynależnością pliku do grupy. Jedyny warunek jest taki, aby plik już należał do niej. W praktyce prawa określające dostępność pliku są więc całkowicie pod kontrolą użytkownika.

W systemach typu trusted określanie uprawnień grupowych jest ściśle regulowane. Zmianę przypisania pliku pewnej grupie tajności i jego dostępności dla innych obiektów może zwykle wykonywać tylko administrator bezpieczeństwa. Chyba że udzieli on innemu użytkownikowi wyraźnej delegacji.

Podejście "co nie jest zabronione, jest dozwolone" jest charakterystyczne dla systemów operacyjnych ogólnego przeznaczenia. Oczywiście, zarówno Unix, jak i Windows zawierają mechanizm kontroli uprawnień do plików. Można w nich również stworzyć oddzielne konta dla różnych użytkowników, a nawet zaimplementować mechanizm kontroli dostępu do zasobów przypominający ten z systemów trusted. Można, ale jest to, po pierwsze, bardzo trudne w praktyce, a po drugie, wciąż byłoby to rozwiązanie nieszczelne.

Prawa dostępu do plików w systemach Unix można precyzyjnie ograniczać. Do dyspozycji są trzy rodzaje operacji: wykonywanie, odczyt i zapis oraz trzy "obiekty", które mogą je obsługiwać - użytkownik, grupa użytkowników (mających identyczne prawa) oraz pozostali. Nadanie w tym modelu jednemu plikowi uprawnień tylko do czytania przez użytkownika A, do czytania i pisania przez użytkownika B jest możliwe przy umiejętnym wykorzystaniu grupy. Jak jednak, w ramach tej samej grupy określić, by dodatkowo użytkownik C mógł do tego pliku tylko pisać? Takiej możliwości nie ma.

Większość systemów typu trusted jest oparta na którymś z systemów Unix, a zatem mają one typową dla nich konstrukcję mechanizmu uprawnień. Naruszenie bezpieczeństwa takiego systemu jest bardzo trudne. W pierwszym rzędzie trzeba pokonać ograniczenia nakładane przez mechanizm kontroli dostępu do informacji zastrzeżonych. Gdy to się uda, trzeba jeszcze przełamać "zwykły" system uprawnień plikowych. Różnica w trudności zadania polega "jedynie" na tym, że w systemach typu trusted użytkownik root nie ma żadnych szczególnych uprawnień.