pld sec team (fwd)

[Krzysiek Taraszka]

IMHO dosyc dobry pomysl :) wart przemyslenia i dalszej doglebnej analizy 
:)

---------- Forwarded message ----------
Date: Sun, 8 Sep 2002 13:33:35 +0200
From: Mariusz Mazur <mmazur w kernel.pl>
To: dzimi w pld.org.pl
Subject: pld sec team

Zacznijmy od tego, że trzeba niejako ustandaryzować źródła informacji. Innymi 
słowy sum bugtraq jest na tyle high-volume, że można coś ominąć. Imho 
najwygodniejszym wyjściem było by stworzenie listy pld-sec-bulk czy coś w tym 
stylu na którą to listę byłby zapisany BQ, jeszcze kilka rzeczy 
@securityfocus pewnie, oraz odpowiednie listy mailingowe krytycznych zasobów 
(czyli na przykład lista odpowiedzialna za sec projektu openssh, openssl, 
etc.). Dużo rzeczy by to ułatwiło, bo mnie osobiście przeraża konieczność 
zapisywania się na szebernaście tysięcy list. Wolałbym na jedną i mieć 
wszystko uporządkowane. Wtedy też wystarczyłoby zapisać na te listy kilka 
osób i prawdopodobieństwo, że coś się przeoczy jest nikłe.

Druga rzecz. Trzeba zrobić listę wszystkich pakietów w pld mających 
bezpośredni wpływ na bezpieczeństwo. Innymi słowy - wszystko co ma 
suidy/sgidy i wszystko co robi za demony. Po tym trza by stworzyć w repo plik 
w którym by były nazwy pakietów, listy mailingowe odnośnie security tych 
pakietów (na te listy miałaby być zapisana lista pld-sec-bulk :), oraz 
miejsca w których się pojawiają nowe wersje/secpatche. W całość też 
wkomponować te same rzeczy z redhata/debiana/whatever (jakieś repo, ftp, or 
sth), bo oni często mają jakieś własne patche sec które preparują 
lepiej/szybciej niż my moglibyśmy to zrobić.

Ostatnia rzecz. Metodologia taka, że ewentualne ciekawe posty z pld-sec-bulk 
są forwardowane na pld-security, po czym omawiane. Problem tylko w tym, że 
takie omawianie polegałoby także na dokładnym omówieniu zagrożeń dla pld 
wynikających z danej dziury (czyli np. czy są eksploity, czy one dają roota, 
etc). Innymi słowy specjalna oferta dla script-kiddie - heterogeniczne 
środowisko (pld), oraz informacje o wszystkich dziurach w nim zawartych (wraz 
ze szczegółowym omówieniem co i jak) i to wszystko *zanim* światło dzienne 
ujrzą poprawione paczki! Chyba wiesz do czego zmierzam? Taka lista miała by 
prawo istnieć tylko jako wewnętrzna lista zaufanych deweloperów (np. minimum 
6 miesięcy stażu or sth), a na zewnątrz mogłyby być wypuszczane tylko 
advisory (specjalna lista stworzona w tym celu na którą mógłby się zapisać 
każdy admin). 

Szczegóły są do ustalenia (czyli na przykład, jeśli 	dana dziura jest znana, a 
jeszcze nie załatana, a jest znany workaround to wypuszczamy advisory z owym 
workaroundem). Oczywiście jeśli to ma być z prawdziwego zdarzenia to jeszcze 
trza by mieć własny katalog na eftepie (dostęp dla sec-teamu z pominięciem 
kloczka), wpis do poldka (tzn żeby poldek -n ra-sec upgrade * działało jak 
trzeba), oraz własny builder/możliwość posyłania zleceń na buildery poza 
kolejką.

Wiem, że to dużo, ale to już byłby sec-team na miarę profesjonalnego. 
Oczywiście nie trzeba mieć tego wszystkiego na raz, ale przynajmniej ten 
własny ftp to jest absolutna podstawa (uzależnienie od kloczka, to tak jakby 
sec-teamu wogóle nie było).


-- 
Każdy człowiek, który naprawdę żyje, nie ma charakteru, nie może go mieć.
Charakter jest zawsze martwy, otacza cię zgniła struktura przeniesiona z 
przeszłości. Jeżeli działasz zgodnie z charakterem wtedy nie działasz w ogóle
- jedynie mechanicznie reagujesz.                 { Osho }