bezpecnost

[Divacky Roman]

On Wed, Mar 01, 2006 at 10:47:34AM +0100, Dan Lukes wrote:
> Divacky Roman wrote:
> > myslim ze pokouset se o tuhle bezpecnost v OS napsanem v Ccku je jako zkouset
> > se prosexovat k panictvi... to proste NEJDE
> 
> 	No, to je zrejme vec schopnosti pouzivat dany nastroj. Nemyslim si, ze 
> existuje jazyk, ve kterem to jde at programator dela cokoliv a naopak, 
> ze existuje jazyk, ve kterem to proste za zadnych okolnosti nejde. 
> Programovaci jazyk je predevsim nastroj. A ten se bud' pouziva spravne 
> nebo spatne - a vysledky jsou podle toho.
> 
> 	Mimochodem, jestlize to "nejde" v C, pak to patrne "nejde" ani v 
> assembleru - a z toho by se zpetne patrne dalo dokazat, ze to "nejde" v 
> zadnem programovacim jazyku.

ok... rekneme ze v jazyce C je pravdepodobnost chyby VYRAZNE vyssi nez v
nejakem jine jazyce (souvisi s neexistenci bezpecnych pointeru, neexistenci GC,
posahanym typovym systemem a celkovou nizkourovnosti jazyka).

> > fbsd ma licenci na coverity a uz se odhalila spousta chyb, navic i fbsd ma
> > nejaky ten audit team, sice o nem neni slyset ale existuje :) a uprimne receno,
> > myslim ze nejvic chyb (jak bezpecnostnich tak vykonostnich tak chyb kter
> 
> 	Ten nastroj neznam, ale vidim, jake chyby se v kodu objevuji. Bud' se 
> ten nastroj nepouziva, nebo existuje prilis mnoho typu chyb, ktere 
> nedokaze odhalit.
> 
> 	Nicmene, nemyslim si, ze odpovednost programatora za kod se da 
> redukovat na to "ze to prohnal nejakym automatizovanym nastrojem".

neni v lidskych silach vyvarovat se chyb typu

if ((bah = malloc(..)) = NULL)

a jsou principielne 2 moznosti jak tomuhle predchazet
1) pouzit jazyk ve kterem tento typ chyby neni popr. je vyrazne redukovat
2) projet ten kod nejakym checkerem na tyto typy chyb

fbsd je napsano v jazyce C a zvolilo druhou moznost, program coverity, ktery
odhaluje podobne typy chyb.

> > zpusobuji pad) se objevi prostym pouzivanim systemu a tady plati ze cim vic
> > uzivatelu tim lip...
> 	
> 	Na, ano, souhlasim, ze zpusob "spustte to a kdyz to nebude fungovat, 
> tak je v tom asi chyba" je zpusob, jak zjistit, ze v kodu je chyba, ale 
> neodvazil bych se ho propagovat jako ten hlavni a nejlepsi mozny. S 
> touto myslenkou v hlave programuje, s prominutim, prase. A ja si, 
> mimochodem, nemyslim, ze vetsina programatoru, kteri prispivaji do kodu 
> by souhlasilo s tim, ze se lze na slusne programovani vykaslat, protoze 
> na chyby se prijde, az to lidi spusti.

nerikam ze se na to ma spolehat, nicmene faktem je, ze se neda deterministicky
postihnout ze v kodu neni chyba. a tak se pouzivaji ruzne stochasticke procesy
kterymy se chyby zjistuji, napr. testovani uzivateli. co se ti na tom nezda?

az napises program, kteremu predlozis kus zdrojaku a on ti napise "program je
bez chyby" tak fajn, ale tohle nejde. vim, ze existuji ruzne verifikacni
formalismy, dokazovani programu (hoare-floyd) atd. ale realne se nic z toho
nepouziva protoze je proste levnejsi zaplatit 10ti studentum 50 korun za hodinu
at to testuji. a i kdyby se to pouzivalo tak to nikdy nebude fungovat 100%,
takove jsou zakony prirody.

reseni vidim tahle
1) pouzivat lepsi jazyky
2) pouzivat lepsi testovaci metody
3) pouzivat run-time verifikace

1cka je u fbsd nesmyslna, 3ka se v urcite mire pouziva (mimochodem, daleko vic
nez u linuxu atp.) ale jen ve vyvojovych verzich a 2ka je mimojine to co ty
kritizujes, tj. testovani davem...

kazdopadne - at se vratim k jakztakz puvodnimu topicu - obsd a fbsd jsou
bezpecnostne (co se tyce kvality kodu) naprosto srovnatelne, s tim ze mam
tendenci verit ze fbsd je na tom lip proste protoze ho pouziva vic lidi...

a uprimne receno myslim ze bysme tuhle debatu meli utnout :)

roman