nebezpecnost sendmailu

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Sobota Březen 9 21:03:38 CET 2002


On Mon, 4 Mar 2002, Ing. Pavel PaJaSoft Janousek wrote:

> Myslim, ze to neni tak davno, co bylo nalezeno par chybicek primo napr.
> v dynamickem linkovani => komponenta A byla sice bez chyby, ale byla
> nahrazena Ax, ktera delala nekale veci a MTA to nemel sanci poznat
> (teoreticky mozna mel, ale ktery software hlida toto? - a hlavne v
> UNIXu?)...

A proc by to nejaky software mel vubec hlidat? Maji si vyrobci aut zacit
lamat hlavu s tim, ze se jejich vyrobek potopi, kdyz ho nekdo zaparkuje
v bazine?

> > Protoze chyby ve spolecnych komponentach jsou porad ty same, ale chyb
> > ve vlastnim kodu bude v jednom pripade treba mnohem mene?
> 
> Ovsem toto je take pouze hypoteza, muze to byt pravda, ale take nemusi
> - treba podle pravidla vice oci vice vidi. Murphyho zakony si ani
> neodvazuji pripominat...:-)

Nemusi. Ale proc by potom nebyla take "pouze hypoteza" myslenka, ze je
urcity (sub)dodavatel duveryhodny a jeho zaruky opravdove?

> > Chyba vezi v tom, ze nekdo huli v aute. Pravdepodobnost, ze nastane
> > havarie kvuli tom, ze volant nesnasi urcitou koncentraci dehtu, je
> > zanedbatelna v porovnani s pravdepodobnosti, ze k havarii dojde kvuli
> > tomu koureni samotnemu (zvlaste je-li provadeno samotnym ridicem za
> > jizdy). ;)
> 
>       A neni to nahodou u MTA vs. napr. viry uplne to same?

Nechapu.

> Mam pocit, ze o tom mluvim porad - vsechny komponenty z duveryhodnych
> zdroju, kde za funkcnost ruci dodavatel a integrator ruci za funkcnost
> celku - nepripada mi to jako (nefunkcni a nefungujici) utopie.

Na nasi planete to chodi tak, ze kdyz uz se podari najit nekoho najit,
kdo je ochoten opravdu ty zaruky dat -- a je dulezite upozornit, ze zaruka
funkcnosti je v zasade daleko slabsi nez zaruka bezpecnosti (*), tak
si za to dotycny necha vetsinou zaplatit tak priserne penize, ze vetsina
potencialnich uzivatelu si logicky klade otazku, zda se jim z toho
plynouci redukce rizika vyplati a zda neni vhodnejsi pouzit jinou metodu,
jak se s problemem vyporadat, vcetne akceptace rizika.

(*) Kriterium funkcnosti je pozitivni, existencne kvantifikovane
("pozadovane operace bude mozno provest"), zatimco kriterium bezpecnosti
je spis negativni, obecne kvantifikovane ("nebude mozno provest nic
nezadouciho"). To take pravdepodobne zduvodnuje, proc je testovani
mnohem mene uspesne u bezpecnostni nez u samotne funkcnosti.

> Kdyz uz jsme u toho, jak by se dal jinak nazvat zdrojak Linuxovyho
> kernelu? (stejne jako p. Kankovsky nezna novejsi sendmaily, ja neznam
> radu 2.3 ci 2.4, ovsem rada 2.0-2.2 je v mnoha ohledech vazne zazitek) -
> a pritom je to komponenta, nad kterou stavime vsechno ostatni...

Velka hromada: urcite. Zprasene: jak co, ale vetsinou bych tak oznacil
spis lokalizovane casti kodu, nez cele subsystemy nebo celou architekturu
(coz tedy neni pripad u toho sendmailu -- ten mi pripadal shnily skrz
naskrz).

V zasade dobre -- i kdyz casto kritizovane (obcas i z ruznych duvodu
opravnene) -- je to, ze i klicove casti obcas projdou dosti radikalni
rekonstrukci, takze se pomerne dobre brani zamotani vnitrni struktury do
jednoho zmateneho gordickeho uzlu i navzdory svemu stale se zvetsujicimu
objemu a slozitosti.

Me posledni vety je tedy treba chapat zaroven jako jista pochvala, ale
i jako varovani, ze prirodnim silam nelze v prime konfrontaci vzdorovat
donekonecna.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



Další informace o konferenci Linux