it-swarm-eu.dev

Zachování tajemství z kořenového adresáře v systému Linux

Hledám způsoby, jak zpřísnit linuxový systém tak, aby i při získání plného přístupu root (prostřednictvím legitimních nebo nelegitimních prostředků) zůstala některá tajemství nepřístupná. Ale nejprve trochu pozadí.

Mnoho různých modelů zabezpečení Linuxu (SELinux, TOMOYO atd.) Se zaměřuje na omezení procesů, které mohou politiky provádět, a na to, aby nepotřebovaly plný přístup root. Jejich cílem je udržet veškeré exploity obsažené v tak, aby nemohly být ohroženy jiné části systému. Zdá se však, že se přímo nezabývají případem, kdy již bylo dosaženo úplného kořenového adresáře - nebo ještě více udržováním tajemství platného uživatele root. Zdá se, že tyto mohou být obvykle vypnuty skutečným rootem za běhu.

Dalším přístupem je omezit způsoby získání úplného neomezeného kořenového kořenového adresáře - například neumožnit veškerý přístup vzdáleně připojenému kořenovému uživateli, ale vyžadovat přihlášení z fyzické konzole. Ani to však není mým cílem - předpokládá se, že jakékoli takové ochrany již byly překonány a kořen je stejně legitimní, jak může být.

Je zřejmé, že kdokoli s fyzickým přístupem ke stroji může všechno uložit na pevný disk a případně také vše uložené v paměti. Je také zřejmé, že pokud má uživatel root pravomoc upravovat binární soubory nebo obrazy jádra, nelze po restartu vydat žádné bezpečnostní přísliby. Zajímají mě pouze útoky, které lze provést bez restartu systému.

Během procesu spouštění bude také s největší pravděpodobností přenášeno tajemství na mnoha místech a je zapotřebí mnoho důležitých bezpečnostních funkcí. Je samozřejmě skvělé, pokud lze během procesu startu chránit také tajemství, ale to, co mi stačí, je krok během startu, kde mohou být zrušena zvýšená privilegia a po kterém již neexistuje způsob, jak je znovu získat.

Jaké jsou tedy možnosti těchto omezení v systému Linux, které zabraňují úplnému uživateli root v přístupu k některým tajemstvím?

  • Mohou na souborovém systému existovat soubory, které nejsou nijak přístupné ani do kořenového adresáře, ale jsou přístupné některým procesům? Některé aktuálně spuštěné procesy nebo dokonce nové procesy spuštěné procesy, které mají aktuálně přístup?

  • Lze v paměti udržovat tajemství spuštěním procesů tak, aby k nim nemohl získat přístup ani kořenový adresář žádným způsobem? Mohou být tato tajemství přenesena na nové procesy některými prostředky, které kořen nemůže ovlivnit?

Tohle je těžké napsat, abych dostal odpovědi relevantní pro mě, takže se pokusím upravit otázku, aby byla v případě potřeby konkrétnější.


Zjevné věci, které si musíme uvědomit a které je třeba omezit, jsou:

  • Zakázat přístup k/proc/mem

  • Zakázat přístup k/proc/<pid>/mem

  • Zakázat přístup k/proc/<pid>/fd/*

  • Zakázat načítání modulů (nejlépe až po načtení některých modulů)

  • Zakažte ptrace přístup k jakémukoli procesu

56
Nakedible

Ve skutečnosti je možné omezit root pokud jeden je připraven definovat takové omezení jako zásadně důvěřovat operačnímu systému. To lze provést pomocí SELinuxu (o kterém vím) a pravděpodobně dalších takových systémů. Nejlepší takový příklad, který jsem viděl u SELinuxu používaného tímto způsobem, je Russell Coker Play SELinux Machine .

Stručný přehled toho, jak to funguje, není v Unixu název root. UID 0 je. UID 0 znamená „věřit všem, co říkám“. Týká se to konkrétně standardního přístupového modelu používaného v Unices, Unixenu nebo pluralitě Unixu.

LSM, nebo Linux Security Modules, vám umožní zapojit se do téměř všeho a provádět audit/popírat akce, jak uznáte za vhodné. V případě SELinuxu jsou oprávnění SELinuxu kontrolována za Unixovými oprávněními, takže váš tok vypadá takto:

Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen

Další fází k pochopení je, že existují nebo byly historicky různé verze SELinuxovy politiky. Než se k tomu dostanu, pochopte to v SELinuxu:

  • inodes mají typy, přípona _t, které by se mohly také nazývat domény; a
  • uživatelé mají role, přípona _r.

Společně řídí, jaká akce může uživatel v dané roli dělat a jaký proces v dané doméně může dělat.

Nyní existují tři hlavní zásady SELinuxu:

  1. cílené. Toto je výchozí zásady pro stolní počítače, jako je Fedora. Myšlenka cíleného je, že kritické systémové služby a démoni jsou spouštěny v doménách, ale mnoho toho, co koncový uživatel dělá, je spuštěno v unconfined_u:unconfined_r:unconfined_t. Žádné ceny za hádání, co to znamená - pokud oprávnění Unixu fungují, SELinux efektivně prochází.
  2. přísné. Tato zásada zahrnuje odebrání unconfined_u úplně. Toto není jednoduchý proces, zejména na ploše Linux (tj. init 5). Konkrétně bezpečnostní model X11 není skvělý a často vyžaduje unconfined_t pro některé aplikace. Vy můžete to udělat , ale očekával bych, že práce s X11 bude těžší (i když ne nemožná), zejména při provádění GUI aplikací, které vyžadují root. Probíhá projekt, který poskytuje podporu funkcím podobným SELinuxu v X, nazvaný XACE (X Access Control Extensions) .
  3. MLS. MLS znamená víceúrovňové zabezpečení a znamená konec řetězce oprávnění: user_u:system_r:httpd_content_t.s0-s2:c5-c7, tj. tato s a c čísla ve skutečnosti něco znamenají. Konkrétně tvoří žádné čtení, žádné zápis nastavení tak, že pokud proces běží jako určitá úroveň, informace, které vidí, budou omezené. Záměrem této úrovně informací je chránit klasifikovaná aktiva - SELinux byl původně vyvinut NSA, pravděpodobně pro tento účel.

To je vaše pozadí. Nyní, podle webových stránek (viz FAQ ) root je UID 0 na hracím automatu; root je však nastaven tak, aby běžel jako user_r a nikoli sysadm_r v striktní . To znamená, že uživatel nebude moci vykonávat administrativní funkce z prostředí.

Co by tedy bylo zajímavé vědět, je stav ostatních procesů, které vyžadují root. Pravděpodobně takové procesy byly náležitě označeny a mají politiky, které jim umožňují přístup, který vyžadují. Otázkou pak je, jak spravujete systém a jak může kterýkoli z těchto procesů spustit prostředí v prostředí daného uživatele. Pokud k tomu může dojít, stále můžete využít exploit.

Protože hrací automat je v současné době mimo provoz (v době psaní), pracuji zde na předpokladech; ale v podstatě byste potřebovali proces spuštěný v sysadm_r as UID 0 jako vaším cílem pro zneužití. Za předpokladu, že takový proces existuje a je využitelný, můžete se stále dostat ke kořenům. Pokud jde o stále možnost administrace pomocí root, existují dvě možnosti, na které bych mohl myslet:

  • Buď existuje důvěryhodný přechod nějakého druhu, což znamená, že root může pak přejít na sysadm_r (méně bezpečné) nebo
  • Pro různé úrovně běhu platí jiná zásada, takže pro správu počítače jeden nastaví úroveň běhu na 1 a politika neomezuje root. Hádám tady.

Souhrn

Pokud je vaše otázka „mohu to nyní snadno a bezpečně udělat?“ odpověď je ne. Pokud vaše otázka zní: „Jsem připraven se dozvědět o SELinuxu, nechte se mnou distribuovat a znečišťujte se spoustou věcí, které nefungují“, je možné omezit root mnohem více, než je vaše průměrná instalace. To však v žádném případě nezpůsobuje nezranitelnost vykořisťování - uživateli neznemožňuje obejít tuto zvláštní kontrolu přístupu v softwaru ani fyzicky.

Takže ano, můžete dělat věci neviditelnými pro root; avšak s výjimkou dodatečné technické zátěže platí stejné upozornění jako u jakéhokoli nastavení řízení přístupu u běžného uživatele - neexistuje žádná stříbrná střela.

Ach a očividná sebepropagace: možná by se mi líbil můj blogový příspěvek na kládání tajemství do softwar . Je to na blogu o zabezpečení stackexchange, takže se mi z toho nedělá tak špatná podpora. Jak vidíte, v zásadě existují mechanismy, které útočníkovi (a vy) znesnadňují život, ale nakonec je to případ „želv po celé délce dolů“, tj. Je to v zásadě nemožné.

33
user2213

Tento problém jsem musel řešit dříve, když jsem k němu přistoupil klient, který si chce zabezpečit „soukromé zprávy“ mezi uživateli na webových stránkách. Za určitých okolností je možné chránit některá data, ale to je přiměřeně omezené.

Mým přístupem bylo jednoduše uložit zašifrovanou verzi poznámky na server a nechat ji zaslat (samozřejmě samozřejmě autentizovanou), poté ji dešifrovat úplně na straně klienta. To znamená, že i v případě úplného ohrožení zabezpečení serveru (tj. Přístup root) zůstaly poznámky zabezpečené. Omezení tohoto však:

  • Chráněná data jsou zabezpečena až do kompromisu a ne později. V závislosti na metodě použité k šifrování informací může kořenový server přimět uživatele k odhalení dešifrovacích klíčů (injekce JavaScriptu nebo pro nativní klienty GUI, vydání kompromitované aktualizace klienta) nebo jiného zachycení dešifrovacích klíčů (pokud jsou klíče založeny) mimo stejnou metodu jako ověřování uživatele, jako je heslo, mohou být zachyceny během procesu ověřování na straně serveru).
  • Přenos vyžaduje dokonalé dopředné tajemství, jinak by šifrovaná data mohla být zachycena, uložena a následně dešifrována po kompromisu, jak je uvedeno výše.
  • To nic nechrání, pokud je klient ohrožen. Pokud nezpracováváte šifrovaná data zcela ve své hlavě (a pokud můžete, zasloužíte si trofej nebo něco), budete dát citlivá data něco a nic není - dokonale nekompromisní.
  • Neexistuje žádný způsob použití tohoto datového serveru (tj. Pro účely indexování), pokud nejsou uložena současně dešifrovatelná/prostá metadata, což může odhalit další informace.

V zásadě to omezuje potenciální využití tohoto scénáře a stále existují slabiny, ale v některých situacích je možné pracovat. Hashování heslem je (rozumně) úspěšným příkladem „root root kompromisní ochrany“, kdy ani fyzický přístup neodhalí hesla uživatele (s výjimkou samozřejmě, že toto heslo je přenášeno po kompromise).

V tomto vláknu jsou i další příklady, které stojí za prozkoumání, ale zamyslete se nad scénářem zpracování na straně klienta a server jednoduše použijete jako službu bezpečného úložiště.

TC

14
TC Fox

Mohou na souborovém systému existovat soubory, které nejsou nijak přístupné ani do kořenového adresáře, ale jsou přístupné některým procesům? Některé aktuálně spuštěné procesy nebo dokonce nové procesy spuštěné procesy, které mají aktuálně přístup?

Ne. Když k nim může proces přistupovat, může také root. Pokud chcete dělat takové věci, budete muset silně upravit celý systém, možná systém, který zavádí neměnné jádro z nějakého zařízení jen pro čtení a který odepírá kořenový přístup k určitým souborům/pamětím a zároveň je povoluje ostatním uživatelům, kteří root mohou “ zosobnit se.

Lze v paměti udržovat tajemství spuštěním procesů tak, aby k nim nemohl získat přístup ani kořenový adresář žádným způsobem? Mohou být tato tajemství přenesena na nové procesy některými prostředky, které kořen nemůže ovlivnit?

Ne. Viz odpověď výše.

Podle definice nemůžete omezit přístup pro root. Pokud omezíte přístup root, pak už to není uživatel root.

Pokud bych chtěl odepřít přístup root k tajemstvím, pokusil bych se je skrýt. Kryptografické kontejnery, možná skryté ve výměnné paměti nebo někde jinde a přístupné pouze pomocí hesla nebo jiného druhu steganografie. Je sakra těžké najít jehlu v kupce sena, i když to není nemožné.

6
Falcon

Existuje celá řada nepřímých způsobů, kterými může root provést spuštění libovolného kódu. Můžete je zakázat a některé bezpečnostní rámce je mohou zakázat, ale ochromují schopnost root provádět úkoly správy.

Například root může číst a zapisovat na disky přímo, čímž obchází veškerá oprávnění pro souborový systém. Tuto schopnost můžete odebrat, ale pak root nebude moci v případě nouze přesunout celý souborový systém na nový disk.

Kořen může načíst moduly jádra, a tak může dělat vše, co může jádro udělat. Tuto schopnost můžete odebrat, ale pak zakážete načítání ovladačů pro média připojitelná za provozu. (To může být žádoucí v 0,001% unixových instalací, ale není to obecný případ.)

Kořen může aktualizovat spustitelné soubory, které uživatelům umožňují přihlášení, například login nebo sshd. Tito démoni zpracovávají autentizaci uživatelů, takže pokud ovládáte jejich kód, můžete vstoupit do zadních vrát. Tuto schopnost můžete odebrat, ale root nebude moci provádět aktualizace zabezpečení.

Root může vytvářet a odebírat uživatele a měnit ověřovací údaje: pokud můžete upravit /etc/passwd Chcete-li přidat účet, můžete jej také upravit tak, aby byl účet dočasně bez hesla. Tuto schopnost můžete odstranit vytvořením některých souborů jen pro čtení, a to i pro uživatele root, ale pak skončíte se systémem, ve kterém nemůžete vytvořit nebo odebrat uživatelské účty bez restartu.

Bezpečnostní rámce účinně vytvářejí uživatele s omezeným přístupem root, kteří jsou root pouze v podmnožině systému - root pouze ve virtuálním počítači, nikoli v „reálném“ systému. Tento omezený kořen ztratí možnost provádění administrativních úkolů v reálném systému. Myslím, že virtualizace je to, po čem jste.

To se dá relativně snadno dosáhnout pomocí selinuxového systému se dvěma klíči: root nemá oprávnění dělat cokoli, a někteří jiní uživatelé bez oprávnění root dělá, takže pro změnu věcí musíte nejprve být non-root jiný uživatel, pak jste "su", aby root provést změnu.

Žádný izolovaný uživatel nemůže nic vidět ani vidět.

Používám to. Funguje to opravdu dobře.

3
cnd

Skutečná potřeba není v otázce dobře definována, ale nebyla zmíněna dvě možná řešení, o nichž se zmiňuje:

  • Kontejnery
  • HSM

Kontejnery - které jsou samozřejmě jen architektonicky citlivějším přístupem k tomu, co se děje po částech pomocí nástrojů, jako jsou vězení a SELinux -, mohou mít význam v souvislosti s přeformulováním otázky - existuje způsob, jak unixová logická logika systém může být vystaven útočníkům tak, že může být ohrožen root, ale tajemství fyzického systému jsou stále chráněna. S kontejnery se blížíme k tomuto cíli. Nedávný příspěvek bezpečnostní skupiny NCC stojí za přečtení: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf

HSM jsou hardwarová šifrovací zařízení, která zabraňují získávání dešifrovacích klíčů fyzickými nebo logickými metodami, takže může být odpověď na otázku přeformulovaná, protože mám tajemství, která musím bezpečně dešifrovat, co mám dělat s klíči.

2
Jonah Benton

Jak řekl Falcon, uživatel root podle definice má přístup ke všem těmto věcem, nebo už to není uživatel root.

Jádro řídí veškerý hardware, takže jakmile jste root, máte stejný přístup. Virtualizaci opravdu potřebujete, takže uživatel root je pouze root pro virtualizovaný operační systém, na kterém běží, a někteří Hypervisor sedí mimo tento root. (nemluvě o tom, že hypervizory nejsou využitelné, ale to, co se snažíte, je ekvivalentní tomu).

2
Bradley Kreider

Vyzkoušeli jste Grsecurity? To může účinně omezit root uživatele všemi možnými způsoby. https://grsecurity.net/

Grsecurity spolu s PaX činí z vaší krabice nedobytnou pevnost ... pokud to uděláte správně

2
Jauzsika