Download: SpolecznoscWywiad

SPOŁECZNOŚĆ
Wywiady
ROZMOWA
Z PAULEM STARZETZEM
LINUX MAGAZINE: Jak to się stało, że za-
jąłeś się bezpieczeństwem?
PAUL STARZETZ: Był to na pewno proces
powolny i stopniowy, ale zawsze fascynowały mnie łamigłówki, do czego w sumie
sprowadzają się zagadnienia związane
z bezpieczeństwem.
LINUX MAGAZINE: Od pewnego czasu zaczęto mówić, pół żartem, pół serio, że
wraz z każdą nową wersją jądra czeka nas
odkrycie nowej dziury przez iSEC. Jak
oceniasz jakość kodu Linuksa pod względem bezpieczeństwa?
PAUL STARZETZ: Ująłbym to inaczej:
z każdą nową wersją jądra czeka nas wbudowanie nowej dziury do jądra, której odkrycie pozostawiono iSECowi. Oczywiście, żartuję. Można by przy tym odnieść
wrażenie, że jakość kodu jądra w ostatnim czasie bardzo spadła, ale to nieprawda! Wiele z ostatnio znalezionych dziur
istniało już od dłuższego czasu, np. takie
do_brk chyba od paru lat. Niestety, było
ostatnio też kilka dziur, których dałoby
się uniknąć, lepiej szkoląc ludzi piszących kod (np. IGMP). Wiele problemów
powraca, bo zmieniają się generacje programistów.
LINUX MAGAZINE: Sporo administratorów korzysta z któregoś z zestawów łat
zmniejszających ryzyko pewnego typu
ataków, takich jak przepełnienie bufora.
Mimo to do tej pory nie udało im się przebić do głównej gałęzi jądra, nawet jako
kod eksperymentalny. Co sądzisz o tej sytuacji? Czy twórcy Linuksa ignorują pewien problem, czy też faktycznie są dobre
powody, by nie włączać – dajmy na to –
OpenWalla do jądra?
PAUL STARZETZ: Są to powody ideologiczno-polityczne. Zresztą główną wadą
Linuksa pod względem bezpieczeństwa
jest jego monolityczna architektura – jeden błąd na poziomie jądra wystarcza, by
100
NUMER 15 KWIECIEŃ 2005
większość tych łat stała się bezużyteczna.
A na drodze do braku błędów w jądrze
stoją takie przeszkody jak jego złożoność
i styl pisania kodu („ręczne programowanie obiektowe”).
LINUX MAGAZINE: Przy okazji wydania
nowej wersji PaX-a mogliśmy poczytać
dosyć zgryźliwe uwagi jego dewelopera
na temat postępowania z poważnymi
błędami znalezionymi w jądrze, a dokładnie braku reakcji ze strony najbardziej zainteresowanych, jak również braku procedur, które zagwarantowałyby,
że łata zostanie naprawiona, nie trafiając
wcześniej w niepowołane ręce. Jak według Ciebie powinien zostać rozwiązany
ten problem?
PAUL STARZETZ: No cóż, u podstaw rozwoju Linuksa nigdy nie leżało 100-procentowe bezpieczeństwo, raczej 100-procentowa kompatybilność. Z tego powodu
w zespole tworzącym Linuksa brakuje ludzi koncentrujących się na jego bezpieczeństwie, a błędy w jądrze są traktowane
jako efekt uboczny jego rozwoju. Moim
zdaniem, problem powinien zostać rozwiązany podobnie jak w zespole BSD,
tzn. powinna istnieć dedykowana sekcja
zajmująca się jakością kodu (zwłaszcza
jakością „świeżego kodu”), która musi
zatwierdzić każdą zmianę w istotnej z
punktu widzenia bezpieczeństwa części
jądra. Niestety, kłóci się to nieco z wyobrażeniami pana Torvaldsa, propagującego 100-procentową wolność i otwartość
kodu.
LINUX MAGAZINE: Czy incydent z vendor-sec i podszywaniem się przy okazji
odkrycia przez Ciebie jednej z dziur spowodował, że zmieniłeś swój stosunek do
sposobu upubliczniania odkrytych
dziur?
PAUL STARZETZ: To pytanie zawiera
założenie, że istnieje coś takiego jak
WWW.LINUX-MAGAZINE.PL
standardowa procedura upubliczniania
dziur. Moim zdaniem, każda dziura
wymaga osobnego podejścia. Oczywiście, można mieć np. jedną procedurę,
na dziury typu „local root”, inną na
dziury „remote root” itd.. Ten incydent
jedynie lekko zmienił kręgi osób, którym w miarę ufałem, jak również moją
opinię o organizacji projektów Open
Source. Mogę w tym miejscu przytoczyć krótką anegdotę: po ukazaniu się
artykułu o uselib () dostaliśmy informację, że ta dziura jest już od około pół roku znana i aktywnie wykorzystywana
w kręgach „black hatów”, podesłano
nam nawet kod eksploita (który u nas
jednak nie zadziałał). Pokazuje nam to,
jak bardzo ważne jest istnienie osób,
które niezależnie zajmują się bezpieczeństwem i w ten czy inny sposób
dzielą się tymi informacjami z użytkownikami.
LINUX MAGAZINE: I na koniec – jakich
szczególnych rad udzieliłbyś dziś administratorom systemów linuksowych?
PAUL STARZETZ: To pytanie jest zbyt
ogólne, administrator to bardzo elastyczne pojęcie. Może powiem, czego im nie
radzę: po pierwsze – używać programów,
których nie rozumieją, po drugie – wyjeżdżać na narty na dłużej niż 2 dni...
REDAKCJA LINUX MAGAZINE
składa serdeczne podziękowania
ministrowi Włodzimierzowi Marcińskiemu,
posłowi Jerzemu Buzkowi,
ministrowi Jarosławowi Pietrasowi
i wszystkim tym, którzy swoim aktywnym zaangażowaniem
przyczynili się do oddalenia
groźby patentów na oprogramowanie
w Unii Europejskiej