it-swarm-eu.dev

Open Source vs uzavřené zdroje

Chápu, že systémy s otevřeným zdrojovým kódem jsou obecně považovány za bezpečnější než systémy s uzavřeným zdrojovým kódem .

Důvody, proč se k nim přistupuje, nebo jejich kombinace, zahrnují: kulturní normy, finanční, právní postavení, národní bezpečnost atd. - to vše nějakým způsobem souvisí s pohledem kultury na účinek otevřeného nebo uzavřeného zdroje tohoto systému.

Jedním z hlavních problémů je bezpečnost. Společným postojem proti systémům s otevřeným zdrojovým kódem je to, že útočník by mohl využít slabost v systému, pokud je znám. Společným postojem proti systémům s uzavřeným zdrojem je to, že nedostatečná informovanost je přinejlepším slabým bezpečnostním opatřením; běžně označované jako zabezpečení pomocí zatemnění .

Otázka zní: Jsou systémy s otevřeným zdrojovým kódem v průměru lepší než systémy s uzavřeným zdrojem? Pokud je to možné, citujte prosím analýzu v co největším počtu průmyslových odvětví, například: software , armáda , finanční trhy atd.

Tato otázka byla IT bezpečnostní otázka týdne .
Přečtěte si 25. května 2012 položka blog pro více informací nebo zadejte svůj vlastní Otázka týdne.

53
blunders

Představa, že software s otevřeným zdrojovým kódem je ze své podstaty bezpečnější než software s uzavřeným zdrojovým kódem - nebo opačný pojem - , je nesmysl. A když lidé něco takového řeknou to je často jen FUD a nepředstavuje smysluplnou diskusi.

Z tohoto důvodu musíte diskusi omezit na projekt konkrétní. Kus softwaru, který škrábe konkrétní svědění, je vytvořen určeným týmem a má dobře definovanou cílovou skupinu. V takovém konkrétním případě bude možné uvažovat o tom, zda bude open source nebo uzavřený zdroj sloužit projektu nejlépe.

Problém s pitchingem všech implementací „open source“ versus všechny implementace „open source“ spočívá v tom, že se nejedná pouze o porovnání licencí. V praxi je open source upřednostňován úsilím dobrovolníka musí, a uzavřený zdroj je nejčastější v komerčním úsilí. Takže ve skutečnosti porovnáváme:

  • Licence.
  • Přístup ke zdrojovému kódu.
  • Velmi odlišné motivační struktury , pro zisk versus pro zábavu.
  • Velmi odlišné situace právní odpovědnosti.
  • Různé a divoce se měnící velikosti týmů a týmové dovednosti.
  • atd.

Chcete-li se pokusit posoudit, jak to všechno funguje pro zabezpečení v celém softwaru vydaném jako otevřený/uzavřený zdroj, jen se zhroutí. Stává se to vyjádřením názoru, nikoli skutečností.

50
Jesper M

Udržovaný software je bezpečnější než software, který není. Úsilí o údržbu je samozřejmě ve vztahu ke složitosti uvedeného softwaru a počtu (a dovednostem) lidí, kteří se na něj dívají. Teorie bezpečnějších systémů opensource spočívá v tom, že existuje „mnoho očí“, které se dívají na zdrojový kód. Ale to hodně záleží na popularitě systému.

Například v roce 2008 byly objeveny v OpenSSL několik přetečení vyrovnávací paměti , z nichž některé vedou ke vzdálenému spuštění kódu. Tyto chyby ležely v kódu několik let. Ačkoli OpenSSL byl opensource a měl podstatnou uživatelskou základnu (toto je konec konců hlavní knihovna SSL používaná pro HTTPS weby), počet a dovednost auditorů zdrojového kódu nebyla dostačující k překonání inherentní složitosti dekódování ASN.1 (část OpenSSL, kde se chyby skrývaly) a zdrojového kódu OpenSSL (upřímně řečeno, nejedná se o nejčitelnější zdrojový kód C vůbec).

Systémy s uzavřeným zdrojem mají v průměru , mnohem méně lidí, kteří provádějí Q&A. Mnoho systémů s uzavřeným zdrojem však platí vývojářům a testerům, kteří se mohou zavázat k práci na plný úvazek. To opravdu není vlastní otázce otevřené/blízké; některé společnosti zaměstnávají lidi k vývoji opensource systémů a je možné, že jeden by mohl vyrábět software s uzavřeným zdrojem zdarma (to je poměrně běžné v případě „freewares“ pro Windows). Stále však existuje silná korelace mezi placenými testery a uzavřeným zdrojem (korelace neznamená kauzalitu, ale to neznamená, že by korelace měly být ignorovány).

Na druhé straně, uzavřený zdroj usnadňuje skrytí bezpečnostních problémů, což je samozřejmě špatné .

Příkladem jsou otevřené i uzavřené systémy s mnoha nebo velmi malými problémy se zabezpečením. Operační systémy opensource * BSD ( FreeBSD , NetBSD a OpenBSD a několik dalších) mají z hlediska zabezpečení velmi dobré výsledky. Stejně tak Solaris, i když se jednalo o uzavřený zdrojový operační systém. Na druhé straně má Windows (měl) v této věci hroznou pověst.

Shrnutí: podle mého názoru je myšlenka „opensource implikuje bezpečnost“ přeceňována. Důležitý je čas (a dovednost) věnovaný sledování a opravě bezpečnostních otázek, což je většinou ortogonální otázce otevřenosti zdroje. Nicméně nechcete jen zabezpečený systém, ale také chcete, aby byl zabezpečen systém, který pozitivně víte (nebýt vyloupen) je důležitá, ale i v noci může spát). Pro tuto roli mají systémy opensource nepatrnou výhodu: je snazší být přesvědčen, že pokud je systém opensource, neexistuje úmyslně skrytá bezpečnostní díra. Důvěra je ale flirtující věc, jak se ukázalo při nedávné tragikomedii kolem údajné zadní vrátky v OpenBSD (pokud vím, ukázalo se, že jde o červený sledě, ale z koncepčního hlediska nemohu být pokud to sám nezkontroluji).

37
Thomas Pornin

Myslím, že nejjednodušší a nejjednodušší je to softwarové inženýrství. Argument obvykle vypadá takto: open source software je bezpečnější, protože můžete viz zdroj!

Máte znalosti softwarového inženýrství, abyste rozuměli jádru shora dolů? Jistě, můžete se podívat na takového řidiče, ale máte úplnou znalost toho, co se skutečně děje, že ano, musí tam být chyba?

Zde je zajímavý příklad: není to tak dávno, co se v jednom z beta jader objevila chyba nulového ukazatele, která byla docela velká věc, objevená chlapem z grsecurity (PaX patche):

To bylo představeno v kusu kódu, jako je tento:

pointer = struct->otherptr;

if ( pointer == NULL )
{
    /* error handling */
}

/* code continues, dereferencing that pointer
   which with the check optimised out, can be NULL. Problem. */

a pointer == NULL kontrola byla kompilátorem správně optimalizována - protože nulový ukazatel nemůže být dereferencován na strukturu obsahující členy, nemá smysl, aby ukazatel ve funkci byl vždy null. Kompilátor poté odebere kontrolu, kterou vývojář očekával.

Ergo, vis vis, shodně se zdrojový kód tak velkého projektu může zdát správný - ale ve skutečnosti tomu tak není.

Problém je zde úroveň znalostí potřebných zde. Nejenže musíte být docela obeznámeni s (v tomto případě) C, Assembly, s konkrétním subsystémem jádra, se vším, co souvisí s vývojem jader, ale také musíte pochopit, co váš kompilátor dělá.

Nechápejte mě špatně, souhlasím s Linusem, že s dost očima jsou všechny chyby mělké. Problém je v mozku za očima. Pokud za vývoj svého produktu platíte 30 whiz dětem, ale váš projekt s otevřeným zdrojovým kódem má pouze 5 lidí, kteří mají skutečnou znalost kódové základny, pak verze s uzavřeným zdrojovým kódem má zjevně větší pravděpodobnost menšího počtu chyb, za předpokladu relativně podobné složitosti .

Je zřejmé, že to platí i pro jakýkoli daný projekt přechodný v čase, jak diskutuje Thomas Pornin.

Aktualizace upraveno tak, aby odstranilo odkazy na gcc, které byly špatné, protože tomu tak nebylo.

17
user2213

Domnívám se, že prostory, které nejvíce využívají k rozlišování mezi uzavřeným a otevřeným zdrojem, jsou velmi dobře definovány. Mnoho z nich je zde uvedeno, oba mají své zastánce. Není překvapením, že zastánci uzavřeného zdroje jsou ti, kteří jej prodávají. Zastánci Open Source také učinili z Nice pěkné a uklizené podnikání (za pár lidí, kteří to přijali jako náboženství).

Hnutí Pro Open Source hovoří k základům, a pokud jde o bezpečnost obecně, zde jsou body, které se nejvíce hodí do diskuse:

  1. Předpoklad přizpůsobení
  2. Předpoklad Licence Management
  3. Předpoklad Open Format
  4. Předpoklad Mnoho očí
  5. Předpoklad Quick Fix

Takže rozebrat to podle předpokladu, myslím, že poslední dvě byly pokryty poměrně stručně ostatními zde, takže je nechám na pokoji.

  1. Přizpůsobení předpoklad
    Pokud jde o zabezpečení, poskytuje přizpůsobení předpoklad společnostem, které adoptují software, schopnost vytvářet dodatečné bezpečnostní kontroly na existující platformě bez nutnosti zajistěte licenci nebo přesvědčte dodavatele, aby něco opravil. Zplnomocňuje organizace, které potřebují nebo vidí mezeru, aby zvýšily celkovou bezpečnost produktu. SELinux je perfektním příkladem, můžete poděkovat NSA) za to, že jste to vrátili komunitě.

  2. předpoklad správy licencí
    Často se objevuje, že pokud používáte technologie F/OSS, nemusíte spravovat technologické licence s třetími stranami (nebo pokud to děláte mnohem méně.), A to může platit o zcela otevřených Zdrojové ekosystémy. Mnoho licencí (zejména GPL) však vyžaduje distributory požadavky a většina reálných prostředí je heterogenní směsicí uzavřených a open source technologií. I když to nakonec v konečném důsledku omezuje výdaje na software, dostupnost zdroje může vést některé společnosti k porušování licencí OSS tím, že zdroj ponechá soukromý, když mají povinnost uvolnit zdroj. To může nakonec proměnit předpoklad správy licencí na odpovědnost (což je argument uzavřeného zdroje proti licencím, jako je GPL.)

  3. předpoklad otevřeného formát
    Tohle je velký a já s tím spíše souhlasím, takže ho budu mít krátký, abych kázal od kázání. Za 30 let chci mít možnost otevřít soubor, který jsem napsal. Pokud je soubor „chráněný“ pomocí proprietárních ovládacích prvků DRM a software, který potřebuji k přístupu, se již neprodává, potíže s přístupem k mému vlastnímu obsahu dramaticky vzrostl. Pokud je k vytvoření mého dokumentu použit formát, který je otevřený a je k dispozici v open source produktu před 30 lety, pravděpodobně jej budu moci najít a legálně jej použít. Některé společnosti skákají na pásmovém voze „Open Formats“, aniž by skákaly na rozjetém ​​voze Open Source, takže tento argument považuji za docela zdravý.

Existuje šestá premisa, kterou jsem neuvedl, protože to není dobře diskutováno. Mám sklon k tomu uvíznout (nazývat to paranoia.) Myslím, že šestým předpokladem je peří v čepici ministerstva obrany po celém světě. To bylo vysvětleno na svět, když část zdroje Windows 2000 byla úniku.

Závazek o odpovědnosti za uzavřený zdroj
Pokud společnost vyrábí uzavřenou knihovnu zdrojových kódů nebo API prostřednictvím několika vydání v průběhu několika desetiletí, měly malé skupiny jednotlivců přístup k tomuto zdroji během celé jeho produkce. Některé z nich jsou auditními skupinami třetích stran a vývojáři, kteří přešli na jiné společnosti/vlády. Pokud je tento kód dostatečně statický, aby byla zachována kompatibilita, jako je předpoklad výhod uzavřeného zdroje, mohou být některé slabiny na mnoho let neohlášeny. Ti, kteří mají přístup k tomuto uzavřenému zdroji, mají vůči němu svobodu spouštět nástroje pro analýzu kódu, aby mohli studovat tyto slabiny. Úložiště chyb těchto obchodů se softwarem jsou plné „drobných“ chyb, které by mohly vést k zneužití. Všechny tyto informace jsou k dispozici mnoha interním jednotlivcům.

Útočníci to vědí a chtějí tyto informace pro sebe. Pokud jste jedním z těchto obchodů, staví se na vnitřní infrastrukturu vaší společnosti obrovský cíl. A za současného stavu se vaše vývojové procesy stávají bezpečnostní odpovědností. Pokud je vaše společnost dostatečně velká a vaše kódová základna je dostatečně distribuována, můžete být dokonce cílem úsilí o infiltraci člověka. V tuto chvíli se Charlie Millerova technika: podplácíte vývojáře dostatkem peněz a on vám napíše, nezjistitelná chyba se stane zřetelnou možností.

To neznamená, že se do produktů OSS nedostane stejným způsobem. Znamená to pouze, že máte sadu dat, která poté, co jsou uvolněna, mohou odhalit slabiny v instalační základně. Pokud ji zachováte v soukromí, vytvořil kódovací dluh vůči zákazníkům nainstalovaným systémům, které nemůžete okamžitě splatit.

13
Ori

Budete se chtít podívat na tyto dokumenty:

Výsledek je, že otevřený nebo uzavřený je přibližně rovnocenný v závislosti na tom, kolik testování se na nich provádí. A „testováním“ nemyslím tím, co dělá váš průměrný podnikový robotický „tester“, ale spíše jako v terénních zkušenostech.

3
Bruce Ediger

Buďme upřímní, když někdo tvrdí, že open source je bezpečnější než uzavřený zdroj, zevšeobecňují to, co se dnes děje v operačních systémech server/desktop, jako je Linux (open source) versus Mac/Windows (proprietární, uzavřený zdroj).

Proč malware má větší pravděpodobnost ovlivnit druhou a ne první? Z několika důvodů, pro které si myslím, že nejdůležitější je ten první (vypůjčený od tato druhá odpověď na otázku označenou jako duplikát tohoto ):

  1. Software nainstalovaný uživatelem v případě linuxové distribuce (nebo jiného OS s otevřeným zdrojovým kódem) je obvykle balen centralizovanou organizací (tj. v případě Ubuntu je to provedeno Canonical a hostováno jím), které hostí binární soubory sestavené ze zdrojů kurátorů/monitorovaných komunitou open source. To znamená, že pravděpodobnost, že uživatel instaluje infikovaný software, nebo pravděpodobnost, že komunita opensource přijme škodlivé změny kódu, je mnohem nižší než v případě Mac/Windows, kde uživatel obvykle instaluje software z mnoha různých míst na webu. , nebo od mnoha různých dodavatelů z AppStores. Existuje také riziko, že servery organizace (např. Canonical) budou hacknuty, ale toto riziko je malé, protože tyto organizace zaměstnávají špičkové IT odborníky pro provozování svých serverů.
  2. Linux (nebo jiný opensource OS) počet uživatelů je mnohem nižší než uživatelé Windows/Mac , takže pak tvůrci malwaru raději necílí na ně (jako výhodu) poměr nákladů/nákladů je v tomto případě nižší).
  3. Linux jako jádro přichází v různých distribucích, ze kterých si můžete vybrat , takže pak by tvůrci malwaru museli vynaložit větší úsilí, aby vytvořili svůj škodlivý kód být kompatibilní s mnoha z nich (takže poměr přínosů a nákladů je v tomto případě nižší).
  4. Linuxové (nebo jiné opensource OSes) zdroje jsou otevřeny pro každého, aby viděli/upravili. To znamená, že když bude nalezena chyba zabezpečení, může ji kdokoli napsat opravu (neexistuje žádný zámek dodavatele, nejste vázáni na konkrétní organizaci, na kterou musíte čekat, aby byla oprava vyvinuta), takže teoreticky bezpečnostní záplaty se objevují dříve než v případech proprietárního softwaru. (V praxi však obvykle neexistuje žádný rozdíl, protože společnosti provozující vlastní platformy, jako jsou Windows a MacOS, jsou velké korporace, které jsou dostatečně kompetentní.)
0
knocte

Článek OpenSource.com od Jim Fruchtermana „ Je váš bezpečnostní software s otevřeným zdrojovým kódem méně bezpečný? “ poskytuje velmi dobrou analogii toho, jak otevřený zdroj, přestože útočníci vědí, jak to funguje, činí tento software bezpečnějším pro koncové uživatele. :

Šifrování považujte za uzamčenou kombinaci bezpečnou pro vaše data. Možná jste jediný, kdo má kombinaci, nebo můžete pověřit výběr několika blízkých spolupracovníků. Cílem trezoru je zabránit neoprávněným lidem v přístupu k jejich obsahu. Mohou to být loupežníci, kteří se pokoušejí ukrást cenné obchodní informace, zaměstnanci, kteří se snaží dozvědět důvěrné informace o mzdách svých kolegů, nebo podvodník, který chce získat důvěrné informace, aby se mohl dopustit podvodů. Ve všech případech chcete, aby váš trezor udržoval vaše věci v bezpečí a chránil před neoprávněnými lidmi.

Nyní řekněme, že volím trezor pro své cennosti. Vyberu Bezpečné číslo jedna, které je inzerováno s ocelovými stěnami půl palce, dveřmi tlustými palci, šesti zamykacími šrouby a je testováno nezávislou agenturou, aby se potvrdilo, že obsah v ohni přežije dvě hodiny? Nebo si vyberu pro bezpečné číslo dvě, bezpečné, které prodejce jednoduše říká, že mu důvěřuje, protože konstrukční detaily trezoru jsou obchodním tajemstvím? Mohlo by to být bezpečné číslo dva je vyrobeno z překližky a tenkého plechu. Nebo by to mohlo být, že je silnější než bezpečné číslo jedna, ale jde o to, že nemám tušení.

Představte si, že máte podrobné plány a specifikace bezpečného čísla jedna, dostačující k vytvoření přesné kopie tohoto trezoru, pokud máte správné materiály a nástroje. Díky tomu je bezpečné číslo jedna méně bezpečné? Ne to není. Zabezpečení bezpečného čísla jedna spočívá na dvou ochranných opatřeních: síla designu a obtížnost uhodnout moji kombinaci. Mít podrobné plány mi pomůže, nebo bezpečným odborníkům, určit, jak dobrý je design. Pomáhá to prokázat, že sejf nemá žádné konstrukční vady nebo druhou kombinaci „zadních dveří“, než má vlastní vybraná kombinace, která otevírá trezor. Mějte na paměti, že dobrý bezpečný design umožňuje uživateli náhodně zvolit vlastní kombinaci. Znalost návrhu by útočníkovi vůbec neměla pomoci odhadnout náhodnou kombinaci konkrétního bezpečného používání tohoto návrhu.

0
Geremia