W czasie prac nad wersją 2.6 jądra systemu Linuks, w kwietniu 2001 roku, na LKML (Linux Kernel Mailing List)
odbyła się dość ciekawa dyskusja na temat różnych rozszerzeń tego systemu w dziedzinie bezpieczeństwa
i możliwości ich integracji.
Linus Torvalds zaproponował wtedy aby rozdzielić politykę bezpieczeństwa od reszty systemu.
W ten sposób powstały Moduły Bezpieczeństwa Linuksa (LSM - Linux Security Modules).
Są to normalne linuksowe moduły, które można załadować w czasie pracy systemu i które przejmują proces
sprawdzania praw dostępu.
Działają one na zasadzie haków (ang. hooks), to znaczy gdy jakaś część jądra musi sprawdzić czy proces
ma uprawnienia do wykonania pewnej czynności, to wywołuje odpowiednią funkcję (przez wskaźnik w strukturze).
Moduł LSM może zarejestrować tę funkcję i w ten sposób decydować o przyznaniu lub odmowie dostępu.
W strukturach opisujących pewne byty jądra (na przykład procesy albo pliki) dodano również pola (typu
void*) w których modul LSM może trzymać swoje dodatkowe dane.
Moduły LSM mają ważne zalety. Pozwalają w przejrzysty sposób oddzielić funkcjonalność jądra od polityki bezpieczeństwa. Umożliwiają też łatwą implementację różnych modeli kontroli dostępu, które wcześniej istniały jako oddzielne, sprzeczne ze sobą łatki. Takie moduły mogą teraz powstawać i być utrzymywane oddzielnie od standardowego jądra. Być może w przyszłości pozwolą na korzystanie z kilku modeli bezpieczeństwa na raz. Są jednak przeciwnicy tego rozwiązania (na przykład autorzy grsecurity), którzy twierdzą że jest bardzo ograniczone i zostało wprowadzone specjalnie dla SELinuksa (co jest częściowo zgodne z prawdą).
Mechanizm modułów LSM został zintegrowany na etapie jąder 2.5 i jest dostępny od początku w jądrach 2.6. W standardowym jądrze korzystają z niego dwa modele kontroli dostępu. Pierwszym z nich jest przepisany z użyciem LSM moduł capabilities znany ze starszych jąder. Drugim, o którym postaram się krótko opowiedzieć jest NSA SELinuks.
SELinuks to moduł LSM, stworzony głównie przez amerykańską NSA, implementujący model Obowiązkowej Kontroli Dostępu (MAC - Mandatory Access Control). Oznacza to, że polityka zarządzania dostępem jest centralnie narzucona przez administratora systemu i nie może być zmieniana przez użytkowników lub procesy.
SELinuks działa obok tradycyjnych uprawnień Linuksa (to znaczy jądro najpierw dokonuje standardowej kontroli, a w przypadku jej pomyślnego przejścia, sprawdzane są jeszcze ograniczenia SELinuksa), nie korzysta też z tradycyjnych identyfikatorów użytkownika i grupy (UID i GID). Pozwala na odebranie procesom (w szczególności demonom) wszelkich uprawnień, których nie potrzebują, co chroni system przed próbami włamań z wykorzystaniem błędów w demonach działających tradycyjnie z uprawnieniami roota. W modelu tym nie ma użytkownika, który może wszystko, dzięki czemu unika się wad standardowego systemu uprawnień (na przykład konieczności istnienia specjalnych programów z ustawionym bitem setuid i problemów w przypadku ich złamania).
W tradycyjnym Linuksie bezpieczeństwo zależy od poprawności jądra, wszystkich uprzywilejowanych aplikacji (a w przypadku gdy niepoprawne uprzywilejowane aplikacje mogą być wykonywane przez zwykłych użytkowników, to również od nieuprzywilejowanych aplikacji i wszystkich użytkowników). Luka w bezpieczeństwie w jednej z tych grup bardzo łatwo może spowodować złamanie całego systemu. Natomiast bezpieczeństwo SELinuksa zależy głównie od bezpieczeństwa jądra i jakości zasad strategii ładowanej do niego w momencie startu systemu. Oczywiście luka w jednej z aplikacji może spowodować uzyskanie przez intruza większych uprawnień (bardzo ograniczonych - tylko tych potrzebnych danej aplikacji) ale nie może zagrozić innym usługom i aplikacjom ani systemowi jako całości.
Jak do tej pory nie znaleziono w samym SELinuksie żadnych poważnych błędów.
Przez pewien czas w Sieci dostępna była maszyna selinux.dev.gentoo.org z zainstalowanym
Hardened Gentoo wraz z SELinuksem (który był jedynym niestandardowym zabezpieczeniem).
Hasło roota zostało ogłoszone w Internecie (zaskakujące, ale brzmiało: gentoo) i każdy mógł spróbować
złamać zabezpieczenia SELinuksa i strategii bezpieczeństwa dostarczanych z Hardened Gentoo.
Przez kilka miesięcy trwania eksperymentu nie udało się to nikomu.
Podobną akcję (tylko mniej nagłośnioną) zorganizowali również deweloperzy Debiana (i także w tym przypadku nikomu
nie udało się złamać SELinuksa).
Mimo oczywistych zalet, SELinuks posiada też wady. Najważniejszą jest chyba młody wiek projektu, mała ilość dokumentacji oraz niedojrzałość wsparcia wśród dystrybucji. Gentoo (eksperymentalne Hardened Gentoo) wspiera SELinuksa ale (na razie) tylko na serwerach. Jedyną dystrybucją, która wspiera SELinuksa także na komputerach biurkowych jest Fedora Core 3, ale z różnych powodów wsparcie jest bardzo niedoskonałe, a dokumentacja prawie nie istnieje (i kończy się to najczęściej wyłączeniem SELinuksa zaraz po instalacji przez większość użytkowników).