Vlákno názorů k článku Kde se berou bezpečnostní mezery? od Jan Kulveit - I přes upřímnou snahu jsem převážně nepochopil, co...

I přes upřímnou snahu jsem převážně nepochopil, co vlastně autor chce sdělit, a kde jsem pochopil, tam spíš nesouhlasím. Takže se asi kvalifikuju za technokrata, který to "neponese rád" :-)

Představy a analogie jsou svůdné, ale nemusí být vždy užitečné. "Kombinace koleček" - tak to není. Vezměmě něco dost jedoduchého, pracujícího v dost homogením prostředí třeba "php redakční systémy" - obsahují méně chyb? Kdepak, mnohé populární jsou děrovaté jak řešeto (pouze je málo útočníků).

"Univerzálnost". To se neudržím, ale to je úplný blábol. Ke slovu počítač lze přidávat všelijaká adjektiva typu "domácí" a kecat o obtížnosti návrhu něčeho unverzálního. Kdesi hluboko však leží pojmy jako "Turingův stroj", nějaké věty o ekvivalenci, "von Neumannův stroj" a tak podobně. Právě že počítače jsou přirozeně univerzální a díky těm hlubokým pojmům v pozadí v principu "umí všechno". Je strašně obtížně obtížné je tomu "odnaučit" a je to častým zdrojem bezpečnostních problémů :-)
Variabilita využití nijak podstatně nesouvisí s "interakcí různých rozhraní".

"Totéž homogenní prostředí ale přispívá k relativně spolehlivému a stálému fungování informačních systémů."
K relativně stálému a spolehlivému fungování "globálních systémů" přispívají jednotné definované protokoly. Homogení prostředí je především levné, spolehlivosti škodí.


Námět na hlubší zamyšlení, kde se berou bezpečnostní "mezery":

Výroba nejrozšířenějšího software dnes znamená unikátní kombinaci podmínek
- Nulová odpovědnost výrobce za chyby, vzniklé škody, záruka...
- Uzavřenost. Není známo nějaké složení, plány... (zdrojové kódy). Nelze se přesvěčit, jaké prasárny se případne skrývají "uvnitř".
- Výrobky se prodávají "jako jablka", od kusu. (Hovoří se o "krádeži" software). Doopravdy ale mají podobu čísel, která lze s naprosto nepatrnými náklady replikovat na mnoho fyzicklýchh nosičů. Ztrácí tak význam řízení jakosti, prototyp,...
- Neexistují normy, certifikace.

Žádná z těhle podmínek není technické povahy.
Není ale třeba zmiňovat filosofii, otázka prostě je, co se výrobcům kancelářského software obchodně vyplatí.

Podstatná je první podmínka.

Druhá je nezajímavá. Moderní auta jsou taky blackboxy, a k ničemu podobnému u nich nedochází. Když dojde, stahuje se celá série a firma se modlí, aby ji stihli stáhnout včas, než se bude platit zmrzačeným a auto bude prohlášeno za "nebezpečné v každé rychlosti".
Ostatně už u škodovky, na které jsem se učil řídit, jsem se sice dokázal přesvědčit, jestli je brzdová kapalina, ale ne jestli není někde nějaká zhůvěřilost, která při prudkém brzdění rupne.

Třetí nerozumím. Prototyp samozřejmě je, otestovat jde, s prodejem jako kusu to nesouvisí.
Jde to testovat. Ale asi se nedělá, protože - podm. 1.

Čtvrtá neplatí. Normy a certifikace existují, ale proč je dodržovat, když je zákazník nechce? A navíc - podm. 1.

Ta první podmínka stačí. Bohatě.

Já jsem ty implikace myslel obráceně - podle mě by k výrazným změnám u software stačilo upravit kteroukoli z uvedených vnějších podmínek.

Auta jsou bezpečná - neplatí pro ně 1., ale ani 3. a 4. Samozřejmě na spoustu věcí v autě je spoustu norem. A automobilce se samozřejmě kontrola jakosti vyplatí, protože stažení každého šmejdu je drahé. Oproti tomu oprava softwarového šmejdu je pro výrbce levná, prostě se umístí záplata.

Podmínka 3. prakticky znamená, že vyrábět šmejdy se u softwaru neprodražuje, samozřejmě souvisí s 1.

Poviné normy a certifikace na bezpečnost kancelářského software neexistují. Normy na bezpečnost software v řadě specifických aplikací existují.
Oproti tomu v ostatním světě jsou normy na bezpečnost třeba i kuchyňských elektrospotřebičů, čím méně poučený uživatel, tím musí být zařízení "blbuvzdornější". A povinost splnit je je daná zákonem, ne jen vůlí zákazníků.

Turingův stroj raději nevzpomínejte. Tato jednoduchá představa matematiků, jak by mohl vypadat počítač, strašným způsobem brzdí teorii potřebnou pro současný rozvoj. Jak třeba Turingův stroj "čeká na další požadavek člověka" (rozuměj třeba kliknutí myší)?
Já osobně jsem přesvědčen, že za programové mezery může další nesmyslná teorie o naprosté nevhodnosti používání GOTO. Hned popíši proč.
Pokud někdo píše nějaký program - a není vyložený flink - tak u každé podmínky se rozhoduje, jak a kdy co učiní, a také má i představu, jakou variantu neuvažuje. Může-li pro nepatřičné varianty udělat jednoduše GOTO PRYC, tak to udělá. Ale když to tak snadno nejde (anebo by se mu za to někdo teoreticky vysmíval), tak se na to vykašle. - A potom už jenom stačí najít vhodnou kombinace neošetřených podmínek.
Takové je prostě moderní programování a tak si všichni na viry musíme zvyknout! Berte to tak, že představy o bezpečných programech jsou nemoderní a také žádný teoretik se něčím tak ubohým, jako jak psát bezpečné programy, nezabývá a zabývat nikdy nebude.

s goto hoooooodně nesouhlasim

Chybovost úměrně roste se složitostí algoritmu. Nedoporučení goto (nikoliv jeho zákaz) plyne ze snahy dekomponovat složitý problém na jednodušší. Když máte funkci dlouhou přes tři obrazovky a v ní tři a více vnořených úrovní tak souhlasím že už Vám z toho bordelu nic než goto nepomůže :-) a to je ten okamžik kdy vzniká maximum chyb.

Snahou je samozřejmě takové funkce nepsat a problém rozdělit do více dostatečně jednoduchých funkcí - při tomhle stylu psaní zaprvé vyloučíte chyby plynoucí z nepřehlednosti a na goto ani nepomyslíte (ne proto že byste se ho bál).

berk

1. S turingovým strojem jste trochu mimo. Ten neslouží jako model, na kterém byste měl postavit počítač s interaktivními hrami. Turingův stroj je teoretická konstrukce, jejímž účelem je umožnit definici toho, co je to vlastně algoritmus a algoritmizovatelná úloha, případně modelování konečnosti a časové složitosti.

2. Striktní zákaz goto v jakékoli podobě hlásala pouze hrstka fanatiků, a i ti nejaktivnější z nich už nejspíš stihli zmoudřet. Ostatní už tehdy tvrdili, že goto minimálně v situacích, které odpovídají céčkovým break, continue, return a exit jsou žádoucím a opodstatněným prvkem jazyka. Nehledě na to, že moderní zpracování chyb, založené na výjimkách (exceptions) je přesně řešením vašeho problému (i když je to vlastně zase maskované goto).

No jo, jenomže nebrzdící auto nebo probíjející mixér či nabíjecí baterka koupená u Ťongů vás může zabít. Takže tyto normy jsou nutné a každý jejich nutnost uzná. Snad i to, že tu baterku je vhodné zabavit.
(Vzpomínám, jak v dobách největšího nařízeného a kontrolovaného! přátelství se SSSR - naším to vzorem - se u nás nesměly prodávat ruské samovary na elektriku. Neměli u našeho vzoru, a asi dosud nemají, nulák. Postupovali dle normy GOST, je nás dost, jak jsem se doslechl na vojně... Přes veškerou ideologickou spřízněnost si nikdo nedovolil povolit ani nařídit povolení nenulovaného spotřebiče 220V s vodou.)

Mizerný SW vás obvykle nezabije. Teda pokud vám nesmazal těsně před důležitou prezentací několikadenní práci a i pak to normální člověk okomentuje několika (mnoha) doprdelemi a lehkými slečnami (popřípadě pokálenými), leč nezkolabuje. Někdo ano.

Takže daly by se napsat normy na bezpečnost SW, ale program to prodraží. A jak správně psal tady někde Dan Lukeš, lidi radši koupí něco levného než bezpečného. Navíc, tu bezpečnost většinou neuvidí, zato dvojnásobnou cenu ano.

BTW - máme normy na vývoj SW a testování. A jsme drazí. Vyrábět kancelářský SW, nikdo by to nekoupil... Taky žádné bohémství, žádný rozlet pro developery, krutá otročina. Potřebná.