Sandbox

Foto: Gandalf

Ve všech verzích operačního systému Mac OS X, až do Mac OS X 10.5 (Leoparda) bylo ovládání přístupu omezeno na bezpečnostní model, který byl označován jako DAC (Diskrétní kontrola přístupu - Discretionary Access Control). Nejviditelnější část tohoto modelu je v implementaci bezpečnostního modelu POSIXU v přístupu k souborům, který nastavuje omezení podle identifikace objektu ve formě příslušného uživatele nebo členství ve skupině.

Obsah

• Příchod modelu MAC
• MAC framework v kódu
• Aplikování Sandboxu na již existující kód
• Příklad Sandbox profilu
• Závěrem

Podobně Access Control List (ACL) je také formou diskrétní kontroly, ačkoliv je mnohem flexibilnější než běžný POSIX model. V takovém modelu, nově vytvářené objekty nebo procesy dědí přístupová práva podle vytvářejícího subjektu, takže jakémukoliv potomkovi jsou přidělena práva jeho rodiče. Klíčovou myšlenkou za DAC modelem je, že bezpečnost objektu je ponechána na jeho majiteli. Majitel objektu má možnost přiřadit různé možnosti přístupových práv k objektu, v rámci omezení DAC implementace. DAC model zde je desetiletí a zanechal tak otisk ve správě jak vytváření objektů/procesů tak pro přístup mezi různými počítačovými systémy díky své přirozenosti mít uživatele ve svém středu.

Nicméně v této implementaci existuje jeden háček. V každém operačním systému musí existovat superuživatel, který má schopnosti obejít všechny omezení na objektech. V POSIXových operačních systémech jako Unix, Linux či OS X tento uživatel existuje ve formě uživatele root. Existence takového uživatele vytváří paradox. Díky existenci uživatele, který má práva úplně ke všemu omezení DAC přestává pro tohoto uživatele platit. Každý proces, který je spuštěn tímto uživatelem navíc získává stejný "božský režim" a má volné pole působnosti v operačním systému. Současně existence superuživatelského účtu se stává vitálním nástrojem pro praktickou administraci datových objektů a systémových zdrojů. V dokonalém světě to nemusí být nic špatného. Bohužel to však není svět ve kterém žijeme a není neobvyklé, že se některé procesy zneužívají. Jestliže je kompromitovaný proces spuštěn superuživatelem, celý operační systém se stává kompromitovaným, včetně všech uživatelských dat.

Příchod modelu MAC

S příchodem Mac OS X 10.5 - Leopardem, Apple zavedl nový nízkoúrovňový přístupový model do svého operačního systému, postavený na modelu MAC (mandatorní kontrole přístupu). Koncepčně systém MAC implementuje omezení postavené na rolích, objektech a úlohách (actors, object, actions). V takovém systému, role typicky předpokládá formu procesu, vlákno (thread) nebo soket. Objektem je typicky nějaký zdroj jako soubor, složka či dokonce TCP/UDP síťový port atd. Úloha je typicky požadavek role aplikovaná na objekt zájmu a která se liší podle typu objektu zahrnutém v požadavku. Pokud se vrátíme zpět k modelu souborového systému: role bude textový procesor, objektem bude .txt soubor a úlohou bude čtení/zápis tohoto textového souboru. Pokud role vyžaduje přístup k objektu, autorizační systém MAC vyhodnotí bezpečností pravidla a rozhodne, zda má být požadavek schválen nebo zakázán. V čistém MAC modelu je vlastnictví objektu nebo procesu bezvýznamné. Individuální uživatelé nemají možnost měnit definovaná pravidla.

Zní vám to povědomě? Důvody mohou být dva. Jednak je to model podobný SELinuxu (Viz odkaz pod článkem na seriál na Rootovi) a je to stejný model, který se používá na TrustedBSD (I když na TrustedBSD je mnohem více propracovaný). Leopard si zval za vzor MAC model z frameworku, který pochází z Trusted BSD (pochopitelně, protože BSD licenci je pro Apple přijatelnější). Tento framework zavádí "píseček", kontrolu přístupových práv, která dovolí vývojáři nebo uživateli aplikovat přístupová práva procesu, omezením práv různým specifikovaným systémovým zdrojům. Omezení jsou obvykle vynucena po přijetí, takže žádný aktivní soubor jím nebude okamžitě ovlivněn. Nicméně jakákoliv další operace open() bude již podrobena zkoumání přístupu podle nových pravidel. Stejně jako u DAC modelu, nové procesy a větve budou dědit přístupová práva jejich rodičů. V Leopardovi mohou být tyto omezení předkompilovány v každém programu nebo aplikovány k jakémukoliv spustitelnému runtime souboru.

V Mac OS X 10.7 se Apple zmiňuje o aplikačním sandboxingu. Popis této funkce však nijak nerozšiřuje již známé informace, které publikoval u Mac OS X 10.6. Nelze tak říci, zda se jedná skutečně o novinku a co bylo změněno.

MAC framework v kódu

Leopardí MAC framework obsahuje pouze základy frameworku z TrustedBSD. Jeho implementace zahrnuje pouze část kontrolních mechanismů, které poskytuje implementace TrustedBSD. Velmi zde chybí většina Security Policy Modulů jako Biba, MLS či FLASK/TE od NSA (který je implementován v SEDarwinovi), ačkoliv jednoho dne je možná uvidíme. Prozatím Apple nabízí vlastní Security Policy Module přezdívaný Seatbelt, který je implementován KEXT (doplňkem kernelu) souborem /System/Library/Extensions/seatbelt.kext. Od systému 10.5.2 jsou funkce Seatbeltu velmi měněny. Jedinou dokumentovanou cestu, jak tyto kontroly nastavit v kódu jsou pomocí sandbox_init() funkce. Využitím této funkce v kódu, umožňuje aplikaci dobrovolně se vzdát určitých přístupů. Funkce sandbox_init() je velmi omezená a obsahuje 5 předdefinovaných konstant:

• kSBXProfileNoInternet - znemožní využívat TCP/IP
• kSBXProfileNoNetwork - znemožní využívat sokety
• kSBXProfileNoWrite - znemožní psaní do všech objektů v systému
• kSBXProfileNoWriteExceptTemporary - znemožní psát do všech objektů v systému, kromě /var/tmp a `getconf DARWIN_USER_TEMP_DIR`
• kSBXProfilePureComputation - znemožní využívat jakékoliv systémové služby

Každá aplikace může tyto konstanty využít pro omezení schopností nového procesu či vlákna, čímž minimalizuje možné škody vzniklé kompromitací procesu.

Takže i když vaše POSIX práv dovolují čtení a zápis souboru, sandbox tomu zabrání a uživatel s tím nemůže nic dělat. Spouštění programu dokonce i s právy superuživatele bude mít stejný výsledek.

V současnosti jsou možnosti, které nabízí Apple ve stylu vše nebo nic, zejména v oblasti souborového systému. Tímto způsobem Seatbelt funguje spíše jako nešikovný meč, který se otáčí ve velkých kruzích ve snaze o bezpečnost. V této formě má Seatbelt minimální využití, kromě velmi jednoúčelových aplikací nebo velmi vzácných aplikací, které nepoužívají síťové spojení jedním či druhým způsobem. Ačkoliv tyto omezení výrazně sníží možnost přijetí tohoto systému, asi by bylo pro vývojáře chybou jej zavrhnout jako celek.

Aplikování Sandboxu na již existující kód

Naštěstí je zde však alternativní využití, ačkoliv není oficiální podporováno. Jak již bylo zmíněno dříve, je možné aplikovat omezení sandboxu na již překompilovaný kód. To je prováděno pomocí aplikace sandbox-exec a používá předdefinované profily umístěné v /usr/share/sandbox, které poskytuje mnohem vyšší úroveň kontroly nad zdroji. Tyto profily používají kombinaci pravidel povolit/zakázat v kombinaci s regulárními výrazy pro specifikování přístupu k systémovým zdrojům. Je zde řada kontrolních bodů, jako síťové sokety, signály, proměnné sysctl, možnosti větvení a spouštění procesu, většina z nich může být vylepšena z velmi dobrou přesností využitím kombinace regulárních výrazů a staticky vnořených sad. Objekty souborového systému a procesy jsou identifikovány POSIX cestami, v současnosti se nekontroluje cíl checksumy nebo digitálním podpisem.

Jak ukazuje příklad sandbox profilu níže, profil může být aplikován na aplikaci, aby jí omezil vytváření odchozích spojení a omezil zápis souborů na dočasný adresáře a složku předvoleb uživatele. Řádka "debug deny" říká seatbeltu, aby zaznamenal všechna porušení pravidel. Toto je velmi užitečné, pokud zkoumáte aktivitu nedůvěryhodného programu na souborovém systému nebo síťovou aktivitu. Poskytuje jednoduchou cestu pro základní forenzní testování programu získaného z nedůvěryhodného zdroje.

Příklad Sandbox profilu

(version 1)
(debug deny)
(allow default)
(allow process*)
(deny network-outbound)

(allow file-read-data file-read-metadata
  (regex "^/.*"))
(deny file-write*
        (regex "^/.*"))
(allow file-write*
        (regex "^/Users/johndoe/Library/Preferences.*"))
(allow file-write* file-read-data file-read-metadata
  (regex "^(/private)?/tmp/"))

(import "bsd.sb")

Aby se sandbox profil aplikoval, je nutné připojit sandbox-exec binárku k cestě k mach-o binárnímu souboru, který je obvykle umístěn v Contents/MacOS/ složce, uvnitř aplikačního balíku. Můžete určit který sandbox profil chcete aplikovat tím, že použijete přepínač -n, pakliže je profil umístěn v /usr/share/sandbox nebo můžete určit celou cestu k profilu pomocí argumentu -f. Carbon aplikace mohou vyžadovat LauchCFMApp wrapper, aby se správně spustily, jako je zobrazeno v následujícím příkladu:

%Cocoa% sandbox-exec -n localonly  /Applications/TextEdit.app
/Contents/MacOS/TextEdit

%Carbon% sandbox-exec -n localonly  /System/Library/Frameworks/
Carbon.framework/Versions/A/Support/LaunchCFMApp  /Applications/
Microsoft Office 2004/Microsoft Word

Závěrem

Bohužel tento systém vypadá, že ještě zdaleka není dokončen a dokonce i některé profily, které nabízí Apple nevypadají zcela funkčně, nebo obsahují neimplementované kontrolní body. Jedním z těchto příkladů může být pokus o implementaci síťových omezení podle IP adresy. Apple poskytuje příklad pro filtrování layer3 v přiloženém profilu, ale ty jsou zakomentovány a po spuštění hlásí syntaxovou chybu. Apple k těmto příkladům uvádí jen nezřetelné varování, že tyto profily jsou považovány za Apple System Private rozhraní a mohou se v průběhu času měnit.

Nicméně není žádný důvod tuto technologii zcela ignorovat. Pokud vezmeme v úvahu, co vše již bylo implementováno, co podle příkladů, které Apple dal do systému se zřejmě chystá implementovat, Seatbelt vypadá, že bude poskytovat velmi jemné možnosti kontroly přístupu. Využitím těchto omezení, aplikace a uživatelé mohou zajistit, že dokonce i nejhorší možný scénář spuštění nepřátelského procesu může být zmírněn nebo zcela zlikvidován. Existuje mnoho situací, kdy tento model v součinnosti s DAC systémem může v reálném světě pomoci: ať již je to eskalace práv běžného uživatele, přiřadit procesu pouze určité zdroje (a tím je chránit před hackovanými procesy) nebo jako forenzní nástroj zjišťování chování aplikace. Poskytnutím těchto možností , nový framework umožní novou úroveň bezpečnosti a kontroly přístup pro celý OS X.

Apple je si nedostatků zcela jistě vědom a postupně zapracovává Sandbox do svých aplikací, naposledy se jednalo o CUPS, který ve verzi 1.4 by již měl být ve vlastním "pískovišti". Objevují se také aplikace, které sandbox využívají (Google Chromium). Zatím to tedy vypadá, že Sandbox má před sebou skvělou budoucnost.