Gentoo Hardened proti jiným distribucím

Je to všechno ve zdroji! Gentoo kalené je bezpečnostně řízená distro kaleného profilu opravdu hodně se stará o to, aby byl opravdu bezpečný.

Ale stojí to za kompilaci? Velká otázka mezi linuxovými fóry.

Pojďme se podívat na tvrzený profil Gentoo z hlediska bezpečnosti:

zatímco přidává nějaké secu je to tak málo, že to ve většině případů nestojí za to. Poskytuje větší zabezpečení na binární distribuci, protože každý má stejné binární soubory a útočník nemusí hádat, kam se může konkrétní část kódu načíst, ale spuštěním distribuce zdroje je váš adresní prostor již docela jedinečný. Jediný případ, kdy poskytuje určité zabezpečení, když se útočník pokouší uhodnout adresu zneužití, takže nesprávný odhad pravděpodobně způsobí selhání procesu a znovu se načte na novou adresu. Máte pro útočníka dostatek cenných údajů potíže, abyste to získali? Pokud ano, měli byste použít tvrzený profil, ale fyzické zabezpečení a šifrování disku je důležitější, protože pokud to za to stojí, bude snazší vás jednoduše okrást.

Uvědomte si, že neexistuje žádný tvrzený profil na ploše, takže samotný bude o něco těžší, pokud ho plánujete použít na ploše.

Dalším důvodem je, pokud chcete použít něco jako SELinux (který nevyžaduje tvrzený profil), který vám poskytuje velmi jemnou kontrolu nad řízením přístupu, ale je také velmi omezující. Myslím, že to stojí jen za to pro velké sítě s mnoha uživateli a různými úrovněmi přístupu k citlivým datům.

Potřeboval jsem některé funkce SELinuxu, ale rozhodl jsem se pro jejich splnění neobvyklým způsobem použít AppArmor, protože SELinux je příliš mnoho potíží. Vše, co AppArmor skutečně dělá, je poskytnout izolaci procesu nebo izolovaný prostor. Pokud útočník získá přístup prostřednictvím exploze, bude mít přístup pouze k souborům, ke kterým má zneužitá služba přístup. Používám ji s profilem catch all, který brání provádění ze všech světových zapisovatelných a domácích adresářů a přístupu ke klíčům ssh / pgp, klíčenkám atd. To funguje dobře pro servery a desktopy a není příliš omezující. A pokud potřebuji spustit kód z mého domovského adresáře pro vývoj, mohu spusťte neomezený shell přes sudo. Mohu nechat notebook odemčený s otevřenou peněženkou (používám modul kwallet pam) a bude pro vás opravdu těžké získat něco jako klíče ssh nebo hesla (mám také záplaty pro kwallet, takže vyžaduje heslo nebo zobrazit uložená hesla), ale programy, které je potřebují, k nim mají přístup.

Ale díky čemu je zatvrzené? podívejme se také na některé z těchto položek:

• PaX je oprava jádra, která nás chrání před přetečením zásobníku a haldy. PaX to dělá pomocí ASLR (randomizace rozložení adresního prostoru), která využívá náhodná umístění paměti v paměti. Každý skořápkový kód musí použít adresu, aby přeskočil na vložený v něm, aby získal provedení kódu, a protože adresa vyrovnávací paměti v paměti je náhodná, je mnohem těžší dosáhnout. PaX přidává další vrstvu ochrany tím, že udržuje data použitá programem v oblasti nespustitelné paměti, což znamená, že útočník nebude schopen spustit kód, který se mu podařilo zapsat do paměti. Aby bylo možné použít PaX, musíme použít jádro s povoleným PaX, jako jsou hardened-sources.
• PIE / PIC (kód nezávislý na poloze): Normálně má spustitelný soubor pevnou základní adresu, kde jsou načteny. Toto je také adresa, která je přidána k RVA za účelem výpočtu adresy funkcí uvnitř spustitelného souboru. Pokud je spustitelný soubor kompilován s podporou PIE, lze jej načíst kdekoli v paměti, zatímco je nutné jej načíst na pevnou adresu, pokud je kompilován bez podpory PIE. PIE je třeba povolit, pokud chceme použít PaX k využití ASLR.
• RELRO (přemístění jen pro čtení): Když spustíme spustitelný soubor, načtený program musí zapsat do některých sekcí, které Po spuštění aplikace nemusí být označeno jako zapisovatelné. Takové sekce jsou .ctors, .dtors, .jcr, .dynamic a .got [4].Pokud tyto oddíly označíme jako jen pro čtení, útočník nebude moci použít určité útoky, které by mohly být použity při pokusu o získání spuštění kódu, například přepsání položek v tabulce GOT.
• SSP ( stack-smashing protector) se používá v uživatelském režimu; chrání před přetečením zásobníku umístěním kanára na zásobník. Pokud chce útočník přetéct zpáteční adresu EIP v zásobníku, musí také přetéct náhodně zvoleného kanára. Když k tomu dojde, systém dokáže zjistit, že kanár byl přepsán, v takovém případě je aplikace ukončena, což útočníkovi neumožňuje skočit na libovolné místo v paměti a odtud spustit kód.
• RBAC (řízení přístupu na základě rolí): Všimněte si, že RBAC není stejný jako RSBAC, který si představíme později. RBAC je řízení přístupu, které může používat SELinux, Grsecurity atd. Ve výchozím nastavení má tvůrce souboru úplnou kontrolu nad souborem, zatímco RBAC nutí uživatele root mít kontrolu nad souborem bez ohledu na to, kdo vytvořil to. Proto všichni uživatelé v systému musí dodržovat pravidla RBAC stanovená správcem systému.

Dále můžeme také použít následující systémy řízení přístupu, které se používají k řízení přístupu mezi procesy a předměty. Normálně musíme zvolit jeden ze systémů popsaných níže, protože najednou lze použít pouze jeden ze systémů řízení přístupu. Mezi systémy kontroly přístupu patří:

• SELinux (Linux se zvýšeným zabezpečením)
• AppArmor (aplikační brnění)
• Grsecurity, která obsahuje různé opravy, které lze použít na jádro ke zvýšení bezpečnosti celého systému. Pokud bychom chtěli povolit Grsecurity v jádře, musíme použít jádro s povolenou Grsecurity, což jsou hardened-sources.
• RSBAC (řízení přístupu založené na sadě pravidel): Musíme použít jádro rsbac-sources vybudovat jádro s podporou rsbac.

Všechno spadá do velké otázky, jak již bylo řečeno? Stojí za kompilaci? Opravdu jde o to, jak nebo co zajišťujete, a stojí za to to úsilí? Nebo budete schopni skutečně zajistit to, co nechcete, aby zvědavé oči viděly?

Komentáře

• Dobře, děkuji za objasnění všech tyto technologie prosazování zabezpečení. Pokud tedy rozumím vašemu názoru, tyto položky jsou velmi užitečné pro zlepšení zabezpečení systému; ale ptáte se " stojí za to kompilace? ". Proč tedy nejsou ve výchozím nastavení povolena v některých hlavních distribucích? Četl jsem, že PaX na ploše může rozbít některé binární soubory (slyšel jsem o java nebo firefox); je to jediný důvod?
• Důvod, proč PaX a grsecurity nejsou v mnoha distribucích výchozí, je způsoben politikou a egem. Vývojáři obou mají osobnosti, které se silně střetávají s vývojovým týmem linuxového jádra. Kromě toho si nepřejí věnovat čas rozdělení své opravy na bloky, které by byly přijaty do upstream, a místo toho využít svůj čas k vývoji více bezpečnostních funkcí.
• Pamatujte také, že grsecurity je ne systém kontroly přístupu. Spender (tvůrce grsecurity) je velmi podrážděný, když mu lidé říkají systém kontroly přístupu a poté jej porovnávají se SELinuxem. : P Grsecurity je kombinace oprav jádra, která zvyšuje zabezpečení jádra odstraněním tříd chyb. Systém řízení přístupu RBAC, který má, je ve srovnání se zbytkem bezvýznamný. Bezpečnostní funkce Grsecurity ' jsou tak rozsáhlé, že by zabraly mnohem více prostoru, než by bylo možné umístit do jednoho příspěvku. Podívejte se na grsecurity.net a podívejte se na docela komplexní seznam.
• zatímco přidává určité zabezpečení, je ' tak málo, že ' to ve většině případů nestojí za to – Uh, to je naprosto nesprávné. A zabezpečení ve skutečnosti nemá vůbec nic společného se skrýváním adres. ' m žasnu , že tato odpověď byla schválena.