Distribuce podle bezpecnosti?

[Vaclav Ovsik]

On Mon, Jun 04, 2001 at 09:29:02PM +0200, Pavel Kankovsky wrote:
> On Mon, 4 Jun 2001, Vaclav Ovsik wrote:

...

> > Viz. http://www.gnupg.org/
> > Vysla oprava zavazne chyby v gnupg, 1.0.6 (2001-05-29).
> 
> Tohle neni moc dobry priklad, protoze tahle dira je opravdovy problem
> jen za pomerne specifickych podminek. (Asi tak jako nesmirne zavazna chyba
> ve formatu OpenPGP objevena slovutnymi kryptology ceske firmy ICZ. ;) )

To prirovnani mi neprislusi komentovat :-).
Samozrejme existuje urcita priorita v zavaznosti chyb,
ovsem myslel jsem, ze lepsi je byt paranoidni v pripade,
ze chyba je tak snadno opravitelna. Samozrejme pokud tvurci
distribuce provedli nejake rozsahlejsi upravy baliku
uz to tak jednoduche byt nemusi. Nevim jak je to v tomto
pripade, tech patchu tam myslim si zase neni tolik.
Predstava, ze mam casem v systemu vice takovych "nevyznamnych chyb",
to mi asi na klidu nepridava.

...

On Tue, Jun 05, 2001 at 12:38:58AM +0200, Milan Kerslager wrote:
> Pokud se jedna o bezpecnostni patch a panuje shoda o jeho reseni
> (trivialnim), je zaplata a nasledne i balicky pro distribuce pomerne brzo
> k dispozici (a ve srovnatelnem case).
> 
> Pokud vznikne nejaky bezpecnostni problem, nebyvaji postizeny *vsechny*
> distribuce. Jednak proto, ze obsahuji ruzne verze daneho programu a jednak
> proto, ze jejich balicky jsou ruzne patchovane a ruzne prekladane (nektere
> problemy se projevi treba prelozenim programu s volbou XY nebo patchem Z).
> 
> Dobry admin si po zjisteni chyby udela sam provizorni bezpecnostni
> opatreni (napr. vyrazeni dotycne sluzby z public pristupu, dodatecne
> firewallove pravidla, sledovani logu, omezeni pristupu luseru ke stroji
> atp.). Dobry admin neaplikuje zaplaty bezhlave, ale s rozmyslem, protoze
> neni vetsi zabava, nez 3x v rychlem sledu "opravit" problem a zavlect si
> do systemu dalsich 10 chyb (rozbiju si i drive funkcni podsystemy).
> 
> > Konkretni priklad, ktery mi dal: Viz. http://www.gnupg.org/ Vysla
> > oprava zavazne chyby v gnupg, 1.0.6 (2001-05-29).
> 
> Nekoukal jsem na to blize, ale u problemu je podminka "if --batch is not
> used", takze na primy dotaz muze (napriklad) nekdo odpovedet "Our
> distribution is not exploaitable because we do not use this" [uz jsem
> takovou odpoved dostal na primy dotaz od RH nekolikrat].
> 
> Jina mozna odpoved je typu: This fix is not correct and do not solve this
> security issue at all, so when you apply it you are *still not* safe. We
> are working on complex solution.
> 
> > Protoze to co ja jako vyvojar sesmolim se sklada z vice baliku
> > (databazovo-webo-a_ja_nevim_co_jeste-aplikace), je asi vhodne abych to
> > pachal a testoval primo na distribuci ktera bude kdesi nasazena na
> > Inet dejme tomu. Neni pro me prenesene uz bezpecnost zase tak
> > druhorada.
> 
> Zadna velka distribuce si nedovoli ignorovat bezpecnostni problemy. IMHO
> je remote exploit zavaznejsi, nez potencialni problem u user-space
> programu, ktery je sice neprijemny, ale vhodnym chovanim (napr. ze na
> server luserove nesmeji) se stava "naprosto" bezvyznamnyn.
> 
> BTW: pokud byste chtel posoudit bezpecnostni hledisko na ruznych
>      distribucich, je rychlost vydavani updatu minoritni, protoze
>      dulezitejsi bude peclivost provedeni distribuce, interni audit
>      distribuce (tj. fixy potencionalnich problemu uz pred jejich
>      vznikem) a tim kvalita jejich bezpecnostnich expertu. K tomu byste
>      potreboval o dost sirsi znalost problematiky a musel byste se
>      podrobne venovat kazdemu jednotlivemu problemu.
> 
> Chci tim take naznacit, ze aplikace ruznych patchu (do jadra nebo do
> aplikaci) muze byt ve svem dusledku kontraproduktivni - napr. falesny
> pocit bezpeci, system slitne kvuli pitome chybe v superbezpecnostnim
> patchu na memoryleak nebo DoS, bezpecnostni opatreni se da nejak obejit
> (napr. nonexec stack patch), admin je ignorant atd.

Tak s tim vsim ja souhlasim. Ostatne na Debian jsem presel proto,
ze se mi zdala metodika sestavovani distribuce propracovana.
To, ze se vyviji pomalu me neprislo zase az tak tragicke.
To co me z uzivatelskeho hlediska nejvic nastve je kdyz se mi veci
meni pod rukama, jeste hur kdyz neni zachovana kompatidebilita
nebo neco prestane fungovat.
Ted jsem trochu nahlodan temi nazory o updatech.

Jeste k tomu srovnani distribuci:
Prislo mi, ze chapete udrzbu distribuce tak, ze
    1) Ignoruju "drobnejsi" bezpecnostni chyby (odstavuju sluzby,
       pamatuju si co je kde blbe a co nesmim nikomu do budoucna
       dovolit apod.)
    2) Pacham patche jeden pres druhy, stejne tu bezpecnost nedosahnu
       protoze tam zavlecu mraky jinych chyb, navic mi nebudou
       baliky ladit dohromady ... (prehanim :-)

Co kdyz existuje distribuce ktera to zvlada delat kvalitne?
No mozna to fakt neni technicky mozne, ale jak je na tom ten Mandrake?
Dejme tomu, ze patchuje dost rychle, ted je tedy otazka, jestli
to neni na ukor jinych vlastnosti.
Zda se, ze zivot si ulehcuji uz tim, ze binary jsou jenom pro i586
jestli se nepletu a baliku asi nebude tolik jako v RH, ale
zase se tvari, ze jsou s RH kompatibilni (coz se mi zda trochu
pofiderni).  Muze nekdo sdelit nejake dalsi omezeni?
Nechce se mi to hned zkouset nekde instalovat ...

Jinak. Neexistuje nahodou nekde zdroj, kde by dokonce rikali, kdyz dojde
k objeveni chyby: "Tyhle a tyhle distribuce jsou vulnerable...",
no to bych toho asi uz chtel moc. :-)

BTW ted jsem si jeste vzpomel, ze nejmenovany clovek se hrozil,
    ze v Debianu je jeste openssh, ketere umi jenom SSH1, ze
    "to je preci crackli uz davno" (asi nejaky ten insertion attack).
    Argumentoval jsem, ze to bude nejspis nejak opatchovano, ale on
    ze to je principialni nedostatek protokolu SSH1.
    Tak to me teda dost zdrtilo, a pokud me nekdo v tomhle smeru
    uklidni tak to budu rad. Fakt nejsem schopen projit ten patch
    a pochopit to. Jak tvrdi onen klasik "Nejsem Ferda Mravenec :-)".

PS: Suse vydalo ten patch pro gnupg taky, v puvodnim prispevku
jsem na ne zapomel, resp. nezjistil to.

-- 
	Vaclav Ovsik		email: Vaclav.Ovsik na i.cz
	ICZ a.s.		phone: +420 19 7488511
				fax:   +420 19 7488506