Edge bude ve Windows 10 virtualizováno kvůli bezpečnosti

Ad Víc očí víc vidí - to je oblíbený mýtus. K tomu aby ty oči viděly, musely by se dívat. A to se neděje. Navíc s počtem očí se počet nalezených bugů nijak zvlášť nezvyšuje. Fallacy 8: "Given enough eyeballs, all bugs are shallow."
http://ff.tu-sofia.bg/~bogi/France/SoftEng/books/Addison%20Wesley%20-%20Robert%20L%20Glass%20-%20Facts%20and%20Fallacies%20of%20Software%20Engineering.pdf strana 140

Mimochodem kdybyste měl pravdu, tak by těžko docházelo k problémům typu Heartbleed, "Debian OpenSSL Security Snafu" atd.

Ad pokud máte (komerční) automat na kontrolu kódu, je pro něho nejlepší reklamou, když najde chyby v nějakém známém OSS projektu - to bude asi tím, že uzavřený kód k analýze nezískáte, a když ano, tak s NDA :)

Ad Příslušné studie si najděte - důkazní tíže je na vaší straně. Minimálně počty bugů v Google Chrome a Firefoxu nevypovídají o tom, že by byl kód nějak kvalitnější.

@ Lael

"důkazní tíže je na vaší straně. Minimálně počty bugů v Google Chrome a Firefoxu nevypovídají o tom, že by byl kód nějak kvalitnější."

Zas to tvoje nepochopení statistik?

Počet bugů vypovídá tak akorát o počtu bugů. Vůbec se nevztahuje na to, jak je SW kvalitní nebo jak aktivně se na něm pracuje. A počet opravených bugů se vztahuje k počtu opravených bugů a k ničemu jinému.

Dokažme si to:

Mám 1k řádků kódu a tam 1 bug v macrech už 15 let nahlášený umožňující třeba eskalaci práv (based on true MS story) a třeba 10 bugů v nějakém zobrazení.
vs.
Mám 1M řádků kódu a tam 400 bugů a 2 z nich umožňují eskalaci práv.

Má otázka: Opravdu počet bugů vypovídá o nějaké kvalitě?

Ale aby ses zase nenechal mýlit, kvalita kódu je komplexní téma, kde nejsou jenom chyby, ale také čitelnost, rychlost, testovatelnost, případně přenositelnost ale také nějaká účelnost a určitě to není všechno . . .

"Mimochodem kdybyste měl pravdu, tak by těžko docházelo k problémům typu Heartbleed, "Debian OpenSSL Security Snafu" atd."

Prosim tě " typu Heartbleed, "Debian OpenSSL Security Snafu" atd."" jsou celkem dost specializované věci a zde to ani tak platit nemůže už z principu. Jenže zde, už víme, že byly odhaleny, přiznány a ihned opraveny. Kdy naposledy třeba MS nechal otestovat své implementace, a pokud se nepletu tak vychází z těch samých knihoven SSL, někým jiným než svým týmem - napíšu omezeným, ale ve smyslu počtu a tedy i variací zkušeností?

Celkově ale ten princip OSS nechápeš. Nikdo snad netvrdí že je to něco samospásného, ale rozhodně jsou na tom takové kódy lépe. Nejenom co do počtu kontroly, ale také co do použití pro vývojáře kteří na to navazují. Dále pak může víc lidí přispět a tím i zlepšit nebo rozšířit funkcionalitu podle toho co jim vyhovuje a případně se to dá přidat pro všechny. Není totiž nic lepšího, než třeba vytvářet komunikaci s binárkou ke které není dokumentace nebo není dokumentace udržovaná a ta pak začne někde bugovat. U OSS se "lehce" podívám. Dovedeš si představit, že by třeba MS měl dělat Arduino a sám vyvýjet všechny knihovny a pak to mít "zdarma" aby podpořil prodej desek - licenci neřeš ( OSS je o přístupu ke kódu, ne o konečné licenci), jenom ten masivní záběr vývoje ke věcem, které jsou OSS, když najednou začne posílat třeba 50k lidí z celého světa oproti dvěma kanclům vývojářů closed source?

Ad Počet bugů vypovídá tak akorát o počtu bugů. Vůbec se nevztahuje na to, jak je SW kvalitní - takže bugy podle vás nejsou relevantní z hlediska kvality kódu? Co je tedy podle vás kvalitou kódu? (vizte též níže)

Ad Má otázka: Opravdu počet bugů vypovídá o nějaké kvalitě? - pokud mám čtečku HTML, která má na práci interpretovat pár set bugů, a má stovky bezpečnostních bugů ročně (opakovaně po více let), tak to opravdu o kvalitě kódu neříká nic dobrého.

Ad nejsou jenom chyby, ale také čitelnost, rychlost, testovatelnost, případně přenositelnost ale také nějaká účelnost a určitě to není všechno - OK, tím odpovídáte na mou první otázku. Za mě jsou zranitelnosti v kódu pro jeho kvalitu výrazně důležitější, než cokoliv jiného. Zvlášť u kódu, který běží na stovkách milionů instalací. Navíc například čitelnost těžko hodnotit objektivně, a velmi těžko pokud zdroják nemáte k dispozici :). A například přenositelnost v řadě případů není vůbec relevantní.

Ad " typu Heartbleed, "Debian OpenSSL Security Snafu" atd."" jsou celkem dost specializované věci a zde to ani tak platit nemůže už z principu - ano, protože těch mnoho očí ve skutečnosti zdrojáky nečte a neanalyzuje.
Ad už víme, že byly odhaleny, přiznány a ihned opraveny - tyhle (a další) závažné byly odhaleny po dlouhých letech, kdy "mnoho očí" mělo podle teorie kontrolovat zdrojáky. Zjevně to nefunguje, což sám přiznáváte.

Ad Kdy naposledy třeba MS nechal otestovat své implementace... někým jiným než svým týmem - a co je špatného na interním code review? MS má 114000 zaměstnanců, takže nevidím důvod, aby si najímal na audit kódu externí společnosti (počet odhalených chyb s větším počtem reviewerů nijak výrazně neroste). Osobně bych se obával spíš open source projektů, které mají pár core developerů, a hromadu přispěvatelů, kteří sice kód pořádně neznají, ale občas pošlou pár řádek kódu. A dál bych se velmi obával toho, že kdokoliv může zanést do open source projektu bezpečnostní problém záměrně. Autor toho kódu může mít čistě virtuální identitu, open source komunita lidi nijak neověřuje. Stačí mu párkrát přispět kusem kódu, tím získat trochu důvěry, a zavést "drobnou chybu" z kategorie "honest mistake". Zrovna vy rád věříte dost divokým teoriím. Jak divoká vám přijde myšlenka, že někdo zavede do open source projektu něco typu "Debian OpenSSL Security Snafu"? Stačí jeden "drobný omyl", Cčko je dost kryptický jazyk. Na www.ioccc.org je dokonce soutěž v tvorbě zdánlivě neškodného kódu, který zavádí skryté chování.

Ad pokud se nepletu tak vychází z těch samých knihoven SSL - ne, MS nevychází z OpenSSL.

Ad ale ten princip OSS nechápeš - ale chápu
Ad rozhodně jsou na tom takové kódy lépe. Nejenom co do počtu kontroly - tady nesouhlasím, protože neexistuje žádný relevantní zdroj, který by takové tvrzení dokázal.
Ad co do použití pro vývojáře kteří na to navazují - tady souhlas. Když mám zdroják, můžu v něm udělat změny. Jenže když udělám změny, nikdo mi nezaručí jejich integraci o upstreamu, a provádět vlastní dokumentaci, testování a hlavně údržbu těch změn je veliká spousta práce. Dále pokud je kód pod licencí typu GPL, tak to znamená, že když se takového kódu dotknu byť jen klackem, tak musím uvolnit zdrojáky vlastní aplikace. A to je z hlediska businessu mimořádně špatné. Proti použití open source například s BSD licencí nemám vůbec nic, pokud je kvalitní. Ovšem upozorňuji že když potřebuji řekněme knihovnu pro rozeznávání barcodů, tak určitě nebudu používat nějakou která je mizerná a nefunguje, jen protože je k ní zdroják.

Ad vytvářet komunikaci s binárkou ke které není dokumentace nebo není dokumentace udržovaná a ta pak začne někde bugovat. U OSS se "lehce" podívám - tady pozor. Pokud se "lehce" podíváte, tak spoléháte na konkrétní zdroják. Jenže ten zítra může vypadat úplně jinak. Garantované je to co je v dokumentaci. Konkrétní (a častý) příklad: vývojář se koukne, kde shell skladuje ikony. Najde je jako resources v knihovně X, takže je odtamtud začne tahat. V příští verzi Windows se ikony shellu změní, a jeho aplikace padá při dotahování resources. Je to triviální příklad, ale demonstruje, že se nikdy nesmí spoléhat na nedokumentované vlasnosti.

Ad Dovedeš si představit, že by třeba MS měl dělat Arduino - MS nabízí například .NET Gadgeteer. Nemáte zdroják k OS, ale to není důvod aby nemohli lidé napsat hromadu knihoven. Nakonec desktopové Windows také nejsou open source, a koukněte se, kolik aplikací pro ně existuje. Nepíše je 50k lidí, ale miliony lidí. Někteří píšou pro Windows open source, jiní freeware, další placené aplikace. Klíčem je oddělit platformu a vývoj nad ní, což se dávno dělá i ve světě open source.

nevazenej a nemilej sasku vyslanej z PR oddeleni Microsoftu...

opensource prohlizec = otevrene priznani vsech chyb, hledat je muze kdokoliv z nekolika miliard

closedsource prohlizec = priznane chyby jsou jen zlomek tech nalezenych, navic se cumulujou pod dalsi, aby to vypadalo ze je jich mene... dale ten prohlizec obsahuje chyby na ktere zamestnanci Microsoftu neprisli, a bez dostupneho zdrojaku jde stale jen o 114000 paru oci (kde jsou PR sasci, uklizecky, manageri a dalsi ktere na tom nic nevidej), pokud by byl otevren tech chyb by take mohlo hledat nekolik miliard paru oci navic....

Žijte ve svých iluzích, jestli vám to vyhovuje. Google Chrome je sice děravý jako řešeto, ale určitě v něm miliardy uživatelů hledají bugy dnem i nocí :D. BTW ty počty chyb jsou od třetích stran, ne od MS.

Jak jsem už psal, když měl MSIE hromadu bugů a Firefox velmi málo, tak to podle vámi podobných bylo proto, že je Firefox coby open source skoro bezchybný. Když má MSIE pár chyb a Google Chrome i Firefox jich mají hromady, tak je to proto, že v open source se chyby lépe hledají a opravují. Jinými slovy na faktech nezáleží, vy si vždy odůvodníte svoje. A s tím souvisí i další odstavec.

Ad nevazenej a nemilej sasku - všiml jste si, že místo mozku máte chrastítko ve tvaru Tuxe?

Laeli, nejsi hlupák proto, že něco nevíš, jsi hlupák, protože se nedokážeš poučit.
HINT: Počet linků hraje roli jenom na přednáškách pro stejné blby . . .

na faktech zalezi... fakt je ze jsi sasek z PR oddeleni Microsoftu...

Minimálně na WIndows XP (= na nich jsem jej zkoušel) bylo možné docílit efektu forku systémovým voláním NtCreateProcess při neuvedení handle (deskriptoru) image nového procesu. Problém samozřejmě leží v tom, že toto volání není zrovna dokumentované a podobně jako se píše v komentáři na abclinuxu, bylo třeba udělat o dost více věcí, než jen zavolat NtCreateProcess, aby vše fungovalo. Navíc je pravděpodobné, že tyto neznámé (ale asi poměrně snadno zjistitelné reverzním inženýrstvím) kroky se trochu měnily s novými verzemi Windows.

Moc nevidím, jak souvisí fork se sandboxingem. Pokud chce proces spustit jiný proces s nižším oprávněním a sdílet s ním nějaké prostředky, tu možnost má. Ale je to pracnější než jedno volání fork.

> Naopak Cygwin ukazuje, jaké zásadní limity má WIN API

Zmiňovaný limit nevidím jako zásadní. Návrháři WIndows zřejmě byli toho názoru, že pokud spouštíme proces, tak bude mít jiný kód a množina sdílených prostředků bude omezená, a tak fork moc nenajde uplatnění.

Ale souhlasím, že jsou věci, které bych přes WIndows API rád udělal a je to trochu problém. Na druhou stranu, když jsem se ptal linuxu znalejších kolegů, zda "linux API" (uvozovky neznamenají urážku) podporuje něco na způsob WaitForMultiple­Objects, tak jsem dostal zápornou odpověď.

Ad Na GNU/Linuxu se udělá jedoduše fork a nebo clone - aha. A tím se vyřeší to aby cílový proces nemohl na FS kam nemá, nemohl posílat X11 events jinému procesu atd.? Ne, nevyřeší. Konkrétní řešení používané Chromem je kombinace user namespaces a seccomp-bpf.
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md

Ad chybějící fork() - fork() je bad practice, protože pro něj potřebujete spoustu paměti. U tradičních Unixů to znamenalo paměťový prostor parenta opravdu zkopírovat. U "nových" implementací se sice používá CoW, ale přesto tu paměť můžete potřebovat. Katastrofa jménem fork() je jedním z důvodů, proč Linux používá ještě větší katastrofy jménem memory overcommitment a OOM Killer.

Ad Cygwin ukazuje, jaké zásadní limity má WIN API - ehm? Windows na rozdíl od Unixů nikdy nepotřebovaly "smrtící" sekvenci fork/exec (kde spuštění 1kB utility z DB enginu s alokovanými 20GB RAM spotřebuje dalších 20GB RAM), a na rozdíl od tradičních Unixů měly od začátku threading, takže potřeba worker procesů byla zcela okrajová. Windows tedy nenabízejí API na něco, co nepotřebují. Samozřejmě je možné fork() emulovat na úrovni kernelu, jak to nakonec dělají Services for UNIX i WSL.
Ad Je dost možné, že jednoho dne i Microsoft začne své aplikace portovat na WSL API - jasně, kvůli volání fork(), které potřebují jen (staré) aplikace psané pro Unixy :)

BTW POSIX ani Linux "kupodivu" nemá API ani na management servisů/daemonů, změnu konfigurace síťových interface, přidání uživatele a další zcela základní operace. POSIX spoustu věcí řeší jen utilitami a nikoliv na úrovni API. Utility pak typicky mají nastavený SUID bit a provedou nějakou "magii", která je specifická pro daný Unix (a klidně pro danou verzi), a typicky nedokumentovaná. V případě managementu servisů/daemonů jde na každém Unixu o různá klubka skriptů, na Solarisu je SMF, na některých distrech se prosazuje systemd, pak je tu launchd, Android init, OpenRC... Bohužel je to klasický unixový chaos, kde deset skupin pracuje na tom samém, a ani jedna neudělá nic pořádně. Stejně jako u náhrady X11 něčím rozumným, která je cca 20 let pozadu. Jediné co na Unixech opravdu funguje je to, co bylo implementováno před těmi cca 20 lety a dále. Od té doby jde jen o stagnaci, opisování funkcionality ze starších komerčních implementací do open source, a chaotický vývoj kde nejen že levá ruka neví co dělá pravá, ale ani palec neví co dělá ukazovák.

Nemáte link na článek, kde tvrdí, že je to "broken"? Že je to složité, to můžu potvrdit :-) – pokud to chcete využít naplno, což třeba právě Chrome sandbox dělá. Kombinuje ale MIC s dalšími bezpečnostními mechanismy (např. job objekty).

btw: Lael Ophir prave ze je z PR oddeleni Microsoftu ktere ho na root.cz vyslalo pred lety jako sveho FUDgenta ;)

Já ti ale neberu to, jak je to na W Vista + IE 7 a jestli to bylo první. Akorát ti říkám, že to není sandbox tak, aby jsi ho mohl srovnávat s Chrome a kdo že ho jako měl dřív . . .