Za kilka – kilkanaście tygodni zespół odpowiedzialny za wydanie NetBSD 4.0 roześle ogłoszenie, zaczynające się od sakramentalnego „The NetBSD Project is pleased to announce…”. Aby zdecydować, czy warto oczekiwać na tę chwilę z zapartym tchem, wypadałoby wiedzieć, czego można się spodziewać po nadchodzącym wydaniu Najbardziej Przenośnego Systemu na Świecie.
Poniższy tekst został oparty na swobodnie wybranych faktach z prezentacji, przedstawionej przez Emmanuela Dreyfusa na zjeździe EuroBSDCon 2006, artykule Recent Security Enhancements in NetBSD autorstwa Elada Efrata oraz własnych doświadczeniach autora.
Falstart czyli „Lepsze jest wrogiem dobrego”
Powyższe słowa, wygłoszone przez Woltera, stanowią doskonałą ilustrację zamieszania, jakie towarzyszyło rozpoczęciu prac nad kolejną wersją systemu. Zgodnie z przyjętymi w projekcie zasadami w początkach sierpnia 2006 w repozytorium projektu oznaczono gałąź netbsd-4, która miała rychło stać się podstawą nowego wydania. Niestety, po paru miesiącach zaczęła ona zdradzać oznaki przysychania i w końcu użytkownicy zostali poproszeni o powrót do rozwojowej gałęzi current.
Przyczyna była prozaiczna: niedługo po rozpocząciu prac nad nową wersją systemu, gałąź rozwojowa została uzupełniona tak dużą liczbą przydatnych poprawek i uaktualnień że przeniesienie ich do gałęzi netbsd-4 okazało się po prostu ekonomicznie nieuzasadnione. W takiej sytuacji zespół nadzorujący wydanie podjął decyzję o likwidacji gałęzi netbsd-4 i wydzieleniu jej ponownie, na bazie już poprawionego i rozwiniętego kodu. Co też uczyniono w początkach grudnia 2006. W chwili obecnej wydanie oznaczone jest jeszcze jako BETA.
Bezpieczeństwo
Przeglądając listę zmian, jakie zaszły od momentu wydania wersji 3.0 nie można oprzeć się wrażeniu, że tym razem główny nacisk położono na rozbudowę mechanizmów bezpieczeństwa. Oczywiście nie znaczy to, że do tej pory były one w jakiś sposób zaniedbywane :). W poniższym opisie, ze względu na ograniczone moce przerobowe, skoncentruję się głównie na nich, pobieżnie wymieniając pozostałe udoskonalenia.
Kernel Authorization Framework
Czyli, skrótowo, kauth. Pozwala na szczegółową kontrolę tego, co poszczególne procesy mogą dokonać w naszym systemie. Od tej pory root może ze szczętem utracić swą, niewątpliwie uprzywilejowaną pozycję, a użytkownik posługujący się loginem www bez problemu nasłuchiwać na porcie 80 – ale tylko w środy o 18:00 UTC ;). Wszystko zależy od naszej fantazji i modułów, które w postanowimy napisać. Brzmi to znajomo, prawda? Bo i funkcjonalnie mechanizm odpowiada znanemu już wielu osobom mechanizmowi Linux Security Modules (nie mylić z SELinux, to jakby inne poziomy). Implementacja obecna w NetBSD wzorowana jest na stworzonym przez Apple rozwiązaniu o tej samej nazwie.
Zgodnie z zasadami obowiązującymi w projekcie zarówno mechanizm kauth jak i sposób tworzenia bardziej kompleksowych reguł bezpieczeństwa zostały szczegółowo opisane w postaci podręcznika systemowego (man).
Osoby zainteresowane tematem powinny (prócz obowiązkowej lektury wspomnianych stron podręcznika) zerknąć na wątki: SE Linux vs SE NetBSD !! oraz Upcoming security model abstraction.
PaX i ProPolice
Oczywiście kauth to nie panaceum na zło tego świata – można postawić tu dokładnie te same zarzuty, co wobec LSM. Po prostu nawet bardzo pomysłowe reguły nie uniemożliwią ataku przez przepełnienie bufora. Nadchodząca wersja NetBSD wykorzystuje niektóre z możliwości oferowanych przez projekt PaX – blokadę wykonywania kodu w segmentach pamięci zawierających dane (MPROTECT) oraz monitorowanie naruszeń ochrony pamięci w procesach (Segvguard).
Dodatkowo, po dołączeniu do dystrybucji kompilatora GCC w wersji 4.1, deweloperzy NetBSD zachęcają do korzystania, z obecnej tam, funkcjonalności pozwalającej na ochronę przed atakiem poprzez przepełnienie stosu (stack-smashing protection). Więcej informacji na ten temat na stosownej stronie podręcznika
VerifiedExec i meta-dane plików
Pierwszy z wymienionych mechanizmów, służący do weryfikacji integralności wykonywanych plików za pomocą wygenerowanych wcześniej sum kontrolnych, nie jest co prawda nowością, jednak uległ pewnym modyfikacjom – m.in. korzysta teraz z nowowprowadzonej funkcjonalności, pozwalającej na dodawanie do plików dodatkowych informacji – w sposób niezależny od zastosowanego systemu plików. Jednym z zastosowań może być stworzenie własnego systemu ACL, innym – przechowywanie sum kontrolnych…
Pozostałe „drobiazgi”
Wygląda na troszkę na kopanie leżącego, ale z kronikarskiego obowiązku należy wspomnieć, że z systemu definitywnie został usunięty Sendmail. Pierwotnie miał on zostać usunięty dopiero po wydaniu NetBSD 4.0, jednak gdy wkrótce po pierwszym problemie zauważono drugi uznano, że nie warto dłużej czekać. Obecnie jedynym MTA w systemie jest Postfix. Użytkownicy Sendmaila mogą w dalszym ciągu skompilować go za pomocą systemu pakietów pkgsrc.
Drugim, wartym odnotowania udogodnieniem, jest zmienna systemowa security.curtain, która uniemożliwia użytkownikom dostęp jedynie do „własnych” informacji systemowych. Czyli polecenie ps pokaże im tylko własne procesy a netstat tylko własne połączenia. Mała rzecz, a czasem cieszy.
Co jeszcze?
Ano sporo. A nawet bardzo dużo bo lista „znaczących zmian” to ponad 300 pozycji. Z masy informacji o nowych sterownikach, narzędziach, uaktualnieniach i wsparciu dla nowych architektur warto wyłuskać:
- obsługę systemu wirtualizacji Xen 3.x (zarówno w dom0 i domU)
- wsparcie dla Bluetooth
- znany z OpenBSD protokół CARP
- system plików UDF
- przeportowane z FreeBSD wsparcie dla FireWire
- obsługę iSCSI
- nowy, wydajniejszy tmpfs (system plików w pamięci operacyjnej)
- wrapper dla NDIS
- obsługę standardu MultiBoot (czyli GRUB powinien załadować nasz kernel bez dodatkowych zabiegów)
- splash-screen (tak, wszyscy na to czekaliśmy 😉
- za okienka nadal odpowiada wysłużone XFree86 – zgodnie z zapowiedziami, implementacja X.Org ma szansę pojawić się dopiero po wydaniu NetBSD 4.0
Czy warto tego używać?
Na to pytanie nie lubię odpowiadać – bo niby skąd mogę wiedzieć, czy NetBSD będzie systemem odpowiednim dla potrzeb danej osoby? Na pierwszy rzut oka nie da się tego określić – a za analizę konkretnych przypadków, to ja biorę pieniążki ;). Mogę natomiast powiedzieć, że warto się z tym systemem zapoznać, zwrócić uwagę na kompletną dokumentację, spójne i przemyślane rozwiązania, stabilne gałęzie wydań – to wszystko przekłada się docelowo na ilość pracy włożonej w uzyskanie interesujacego nas efektu i stabilność docelowego rozwiązania.
Archiwalny news dodany przez użytkownika: aniou.
Kliknij tutaj by zobaczyć archiwalne komentarze.