Podepsané spustitelné soubory pod Linuxem

Uvědomuji si, že je to prastará otázka, ale právě teď jsem ji našel.

Před chvílí jsem napsal podepsanou podporu spustitelných souborů pro linuxové jádro (kolem verze 2.4.3) a měl jsem nainstalovaný celý toolchain pro podepisování spustitelných souborů, kontrolu podpisů na execve(2) čas, ukládání informací o ověření podpisu do mezipaměti (vymazání ověření, když byl soubor otevřen pro zápis nebo jinak upraven), vkládání podpisů do libovolných programů ELF atd. Zavedlo to určité snížení výkonu při prvním spuštění každého programu (protože jádro musel načíst celý soubor, spíše než jen vyžádat stránkování potřebných stránek), ale jakmile byl systém v ustáleném stavu, fungoval dobře.

Ale rozhodli jsme se to přestat sledovat, protože se potýkal s několika problémy, které byly příliš velké na to, aby ospravedlnily složitost:

• Ještě jsme nevybudovali podporu pro podepsané knihovny . Podepsané knihovny by také vyžadovaly úpravu ld.so zavaděč a dlopen(3) mechanismus. Nebylo to nemožné, ale komplikovalo to rozhraní:měli bychom nechat zavaděč požádat jádro o ověření podpisu, nebo by se měl výpočet provádět výhradně v uživatelském prostoru? Jak by se dalo chránit před strace(2) d proces, pokud se tato část ověření provádí v uživatelském prostoru? Byli bychom nuceni zakázat strace(2) zcela na takovém systému?

  Co bychom udělali s programy, které dodávají svůj vlastní zavaděč?

• Velké množství programů je napsáno v jazycích, které se nekompilují do objektů ELF. Potřebovali bychom poskytnout konkrétní jazyk úpravy na bash , perl , python , java , awk , sed , a tak dále, aby každý z tlumočníků mohl také ověřovat podpisy. Protože většina těchto programů je prostý text ve volném formátu, postrádají strukturu, díky které bylo vkládání digitálních podpisů do souborů objektů ELF tak snadné. Kde by byly podpisy uloženy? Ve skriptech? V rozšířených atributech? V externí databázi podpisů?

• Mnoho tlumočníků je dokořán o tom, co dovolují; bash(1) může komunikovat se vzdálenými systémy zcela sám pomocí echo a /dev/tcp a lze jej snadno oklamat, aby provedl cokoli, co útočník potřebuje. Ať už jste podepsali, nebo ne, nemohli jste jim věřit, jakmile byli pod kontrolou hackera.

• Hlavním motivátorem podpory podepsaných spustitelných souborů jsou rootkity, které nahrazují systémem /bin/ps , /bin/ps , /bin/kill , a tak dále. Ano, existují další užitečné důvody, proč mít podepsané spustitelné soubory. Rootkity se však postupem času staly podstatně působivějšími, přičemž mnoho z nich se spoléhalo na jádro hacky, aby skryly své aktivity před administrátory. Jakmile je jádro hacknuto, celá hra je u konce. V důsledku sofistikovanosti rootkitů upadly v hackerské komunitě nástroje, o kterých jsme doufali, že zabráníme jejich použití.

• Rozhraní pro načítání modulů jádra bylo široce otevřené. Jakmile má proces root bylo snadné vložit modul jádra bez jakékoli kontroly. Mohli jsme také napsat jiný verifikátor pro moduly jádra, ale infrastruktura jádra kolem modulů byla velmi primitivní.

Model GNU/Linux/FOSS ve skutečnosti podporuje neoprávněné manipulace - svého druhu. Uživatelé a tvůrci distribucí musí mít možnost volně upravovat (poškozovat) software tak, aby vyhovoval jejich potřebám. Dokonce i pouhá rekompilace softwaru (beze změny zdrojového kódu) pro přizpůsobení je něco, co se provádí poměrně často, ale narušilo by to podepisování binárního kódu. Výsledkem je, že model podepisování binárního kódu není příliš vhodný pro GNU/Linux/FOSS.

Místo toho se tento druh softwaru více spoléhá na generování podpisů a/nebo bezpečných hashů zdrojových balíčků. V kombinaci se spolehlivým a důvěryhodným modelem distribuce balíčků to může být stejně bezpečné (ne-li více, z hlediska průhlednosti do zdrojového kódu) jako podepisování binárního kódu.

Modul jádra DigSig implementuje ověřování binárních souborů podepsaných nástrojem nazvaným bsign . Od verze 2.6.21 linuxového jádra na něm však nebyla žádná práce.

Podívejte se na toto:http://linux-ima.sourceforge.net/

Zatím nepodepisuje, ale stále umožňuje ověření.