Technologie zapewniające bezpieczeństwo w systemach operacyjnych.

Bezpieczeństwo lokalne

Bezpieczeństwo lokalne polega na ochronie integralności systemu przed lokalnymi użytkownikami. W praktyce odbywa się to przez rozróżnianie użytkowników, nadawanie im praw, ograniczeniu dostępu do różnych zasobów.

Ochrona sytemu plików

Unix

Ochronie systemu plików służą czynności które może wykonać root:

• ograniczyć dostęp do poleceń setuid/setgid,
• włączyć opcję nodev (brak urządzeń w tym systemie plików), noexec (brak praw do wykonywania plików binarnych) w tablicy /etc/fstab dla partycji gdzie mogą pisać inni użytkownicy niż root,
• nadać prawo read-only dla możliwie największej ilości plików,
• skonfigurować /etc/export z opcjami 'nosuid', 'nodev', 'noexec' (dla podmontowywanych systemów plików w sieci np. NFS),
• nałożyć ograniczenia na system plików dla poszczególnych użytkowników (możliwe za pomocą modułu pam),
• unikać tworzenia plików, w których wszyscy mogą pisać,
• unikać plików nie posiadających właściciela,
• ograniczanie plików .rhosts, lub usunięcie ich z systemu,
• skonfigurować polecenie umask służące do ustalenia domyślnego trybu tworzenia plików (jest on zdefiniowany w pliku /etc/profile).

O prawach dostępu do plików w Unixie decydują następujące atrybuty pliku:

• właściciel - kto ma prawo do ustalania praw dostępu do danego węzła,
• prawa - do odczytu, zapisu, wykonania,
• atrybut sticky bit na katalogu pozwala użytkownikowi usuwać pliki i pisać tylko do tych plików, których jest on właścicielem, lub do których ma nadane odpowiednie prawa, nawet jeżeli ma on prawa do pisania w całym katalogu (ważne w przypadku katalogów takich jak /tmp, do którego wszyscy mają prawa),
• gdy na pliku wykonywalnym atrybut SUID jest ustawiony na prawa właściciela, proces wykonujący ten plik ma zagwarantowane takie prawa jak właściciel pliku (a nie procesu),
• atrybut SGID dla plików - analogicznie do SUID; dla katalogów sprawia, że pliki utworzone w tym katalogu mają grupę ustawioną na grupę katalogu.

Oprócz tego, istnieją narzędzia służące do wykrywania potencjalnych włamań do systemu. Programy takie jak Tripwire, Aide, czy Osiris tworzą bazę danych sum kontrolnych określonych plików binarnych i każdorazowo sprawdzają ich zgodność z sumami rzeczywistych plików istniejących w systemie.

Zabezpieczają one np. przed atakiem konia trojańskiego. Polega on na tym, że nowe oprogramowanie jest zakamuflowanym wirusem lub spełnia inną rolę niż się od niego spodziewamy. O szkodliwym skutku działania takiego software'u informują powyższe narzędzia, jednak, żeby takiego włamania uniknąć, należy zawczasu uważnie sprawdzać żródło instalowanego programu, weryfikować podpisy elektroniczne, certyfikaty itp. (o tym w części o bezpieczeństwie w sieci).

Solaris

Do zapewnienia bezpieczeństwa systemu plików Solaris dostarcza narzędzie Automated Security Access Tool - ASET. Pozwala ono na całościową kontrolę nad ustawieniami w systemie, ustawienie poziomu jego bezpieczeństwa, informowanie o zagrożeniach. ASET uruchamia się okresowo i sprawdza m. in. następujące parametry w systemie:

• istnienie hasła na EEPROM chroniącego przed uruchamianiem systemu w trybie pojedynczego użytkownika,
• bezpieczne ustawienia zmiennej UMASK trzymającej domyślne prawa dla nowoutworzonego pliku w systemie,
• bezpieczne ustawienia zmiennej PATH trzymającej katalogi przeszukiwane w celu znalezienia wołanego pliku wykonywalnego,
• prawa w systemie plików,
• istnienie nowych programów setuid,
• zawartość .rhost, /etc/passwd, /etc/group,
• rozmiary plików w /usr/bin oraz /bin.

ASET może być skonfigurowany by odpowiednie ostrzeżenia były wysyłame mailem do administratora.

W zależności od poziomu bezpieczeństwa na jaki jest skonfigurowany ASET, sprawdza on odpowiednie ustawienia i zezwala na większe lub mniejsze prawa dostępu do zasobów w systemie.

Ochrona plików w Solarisie może być regulowana sposobem "Unixowym", czyli poprzez ustawianie 10 bitów praw dostępu. Ta metoda ma taką wadę, że prawa mogą być ustawiane na poziomie grupy, a nie pojedynczego użytkownika. Dlatego też Solaris został zaopatrzony w tzw. Access Control Lists (ACL), które pozwalają na kontrolę praw na poziomie indywidualnego użytkownika i zasobu. Każdemu plikowi jest przypisana oddzielna lista praw dostępu dla użytkowników. Pozwala to na większą granulację praw, większe możliwości kontroli dostępu.

Windows NT

Ochrona zasobów w systemie Windows NT opiera się na dwóch funkcjach:

• audytowanie - logowanie wszystkich akcji użytkownika w systemie,
• ochrona praw dostępu do obiektów w systemie.

W NT istnieje podział na prawa i przywileje. Prawa są przypisane konkretnym obiektom i dotyczą użytkowników np. prawo do czytania z pliku A przez użytkownika X. Prawa do obiektu są umieszczone w ACL (lista praw dostępu) danego obiektu. Przywileje to predefiniowane prawa do operacji w systemie np. ładowanie sterowników czy debugowanie aplikacji. Przywileje są przypisane konkretnym użytkownikom - w strukturze danych identyfikującej danego użytkownika znajduje się tzw. access token określający przywileje danego użytkownika w systemie. Przywileje nadpisują zatem prawa do określonych obiektów w systemie.

Security Descriptor

Każdy obiekt - plik, łącze nazwane, obiekt użytkownika czy jądra - ma przypisany SD - security descriptor. Taki deskryptor określa:

• właściciela obiektu
• ACL (listę praw dostępu dla poszczególnych użytkowników i grup).

Są dwa rodzaje ACL:

• DACL (discretionary ACL) jest kontrolowany przez właściciela obiektu i określa prawa poszczególnych użytkowników do danego obiektu,
• SACL (system ACL) jest kontrolowany przez administratora systemu i reguluje audytowanie.

W DACL dla każdego użytkownika czy grupy istnieje ACE (access control entry). Jednostka taka składa się z informacji: rodzaj prawa (ACCESS_ALLOWED_ACE_TYPE/ACCESS_DENIED_ACE_TYPE), typ prawa (pisanie/czytanie/..), id grupy lub użytkownika, którego to prawo dotyczy. Jeżeli obiekt nie ma żadnych ACE w swoim DACL to znaczy, że żadne prawa nie zostały dla niego określone czyli faktycznie wszelkie prawa są do niego zabronione. Z drugiej strony, jeśli obiekt nie ma przypisanego DACL, to żadna ochrona nie jest mu przypisana, czyli faktycznie każdy ma do niego dostęp. Domyślnie nowoutworzony obiekt ma przypisaną pustą DACL.