Portál AbcLinuxu, 24. dubna 2024 07:25
Aktuální verze jádra: 3.4-rc2. Řada 2.4 končí. Nová wiki bezpečnostního subsystému. SCHED_DEADLINE se vrací. Nový přístup k uživatelským jmenným prostorům (kontejnery).
Aktuální vývojová verze jádra je 3.4-rc2 vydaná 7. dubna. Obsahuje spoustu oprav; Linus se také rozhodl přetáhnout přípravné patche pro přepracování mapování DMA. To by ale měl být konec významných změn v tomto vývojovém cyklu. Odteď budu co se přetažení týče přísnější, vyskytlo se spousta „šumu“, nikoliv jen čisté patche. Krátký přehled změn naleznete v oznámení.
Stabilní aktualizace: za poslední týden žádné nevyšly. Verze 3.0.28, 3.2.15 a 3.3.2 se aktuálně revidují. Všechny tři verze obsahují dlouhý seznam oprav; jejich vydání se dá očekávat 13. dubna nebo později.
Více než osm let po vydání verze 2.6.0 Willy Tarreau oznámil, že už nebude vydávat žádné aktualizace řady 2.4. Pro potřeby těch, co z nějakého důvodu nemohou upgradovat, udržuje strom v gitu s občasnými opravami, ale bez jakýchkoliv záruk.
Vývojáři zabývající se bezpečností v jádře už nechtěli dále čekat na návrat wiki systému kernel.org. Proto najdete všechny informace k vývoji zabezpečení v jádře na kernsec.org. Obnova obsahu wiki kernel.org ještě asi chvíli potrvá.
Plánovače na bázi deadline se tu už mnohokrát diskutovaly. Ve zkratce jde o to, že namísto priorit ohodnocuje deadline plánovač každý proces maximálním potřebným procesorovým časem a termínem („deadline“), do kterého musí daný čas obdržet. Správně napsaný deadline plánovač je schopen zajistit, že každý proces dodrží dané termíny a odmítne přitom jakoukoliv úlohu, která by způsobila nesplnění termínu. Patche doplňující deadline plánovač do Linuxu už existují několik let, ale jejich cesta do jádra byla poněkud pomalá, v poslední době dokonce velmi pomalá, protože hlavní vývojář se začal věnovat jiným projektům.
Juri Lelli se stal novým vývojářem těchto patchů; Juri zaslal novou verzi těchto patchů, aby nanovo rozjel diskuzi. Patch se od posledně moc nezměnil: reaguje na připomínky a má lepší mechanismus pro migraci. Plánem je opravovat nedostatky, aby se deadline stal vhodným pro produkční nasazení a aby se nakonec dostal do hlavní řady jádra. Proto vznikl nový Git repozitář, dále pak aplikace pro testování deadline plánování a mailing list. Dá se očekávat, že Juri bude vděčný za patche a testování.
"Kontejnery" se dají považovat za lehkotonážní podobu virtualizace. Virtualizovaní hosté vypadají, jako by běželi na svém vlastním dedikovaném hardwaru; kontejnery zato běží na jádře hostitele, jenže v prostředí, které dává iluzi, že mají celé jádro pro sebe. Výsledek je efektivnější; na jediném systému je obvykle možné provozovat více kontejnerů než virtualizovaných systémů. Nevýhodou z pohledu uživatele je flexibilita; virtualizovaní hosté mohou mít vlastní jádro a mohou tedy provozovat libovolný operační systém. Hosté v kontejneru musí používat to jádro, jaké používá hostitel.
S kontejnery se pojí další nevýhoda, kterou uživatelé nemusejí nezbytně zaznamenat: jejich jaderná implementace je v mnoha ohledech značně komplexnější. V systému, který podporuje kontejnery, musejí všechny globálně viditelné prostředky být zaobaleny ve vrstvě jmenného prostoru, který každému poskytuje vlastní pohled. Na linuxovém systému je spousta prostředků: například ID procesů, souborové systémy nebo síťová rozhraní. Dokonce i název systému a čas se mohou mezi kontejnery lišit. Následkem toho je to, že navzdory rokům snažení Linuxu stále chybí pořádná podpora kontejnerů, i když podpora virtualizace má už dlouhou dobu stabilní základy.
Práce na implementaci kontejnerů ale pokračuje; posledním dílkem je nová sada patchů pro uživatelské jmenné prostory od Erica Biedermana. „Uživatelský jmenný prostor“ lze vnímat jako zaobalení ID uživatele/skupiny a souvisejících práv; umožňuje vlastníkovi kontejneru být uživatelem root v rámci daného kontejneru a přitom izolovat zbytek systému od uživatelů v kontejneru. Náležitá implementace uživatelských jmenných prostorů byla z řady různých důvodů vždy problémem. Jaderný kód byl napsán s předpokladem, že každý proces má jedno, globálně uznávané UID; co se stane, když bude proces mít vícero UID v různých kontextech? Není obtížné si představit, jaké chyby by mohli vývojáři s UID udělat – šlo by o chyby, které by mohly vést k bezpečnostním chybám v hostitelském systému. Obavy z takových chyb a samozřejmě i obecná složitost problému způsobují, že se do jádra plná podpora uživatelských jmenných prostorů ještě nedostala.
Ericův patch na to jde trochu jinak, ve snaze zneviditelnit uživatelské jmenné prostory a současně odhalit chyby v kódu, hned jakmile jsou napsány. Proto patch zavádí nový typ, který má vyjadřovat „jaderná UID“ – kuid_t; pak je tam i typ kgid_t. Jaderné UID má popsat identitu procesu na základním systému bez ohledu na jakákoliv UID, která se vyskytují v kontejnerech; je to hodnota, která se používá hlavně při ověřování práv. Jaderná ID procesu se mohou (nebo nemusí) lišit od ID viditelných v uživatelském prostoru; proces to nemá jak poznat. Jaderná ID existují pouze za účelem ověření identity procesu v jádře samotném.
Ve zmiňovaném patchi je kuid_t typedef na strukturu s jediným polem; hlavním důvodem jeho existence je nebýt typově kompatibilní s obyčejným integerem [celočíselným typem], který se v jádře používá pro UID a GID. ID specifická pro kontejner mají původní integerové typy (uid_t a gid_t). Následkem toho je to, že jakákoliv snaha míchat jaderná ID s ID specifickými pro kontejner skončí chybou při kompilaci. To by mělo zneškodnit celou skupinu potenciálních chyb.
Typ uid_t, který je při používání v jádře neprůhledným typem, potřebuje sadu pomocných funkcí. Porovnání lze například dělat pomocí funkcí jako uid_eq(); podobné funkce existují pro většinu aritmetických porovnání. Pro většinu užití to postačuje. Bez ohledu na jmenný prostor jsou údaje o procesu uloženy v globálním prostoru kuid_t, takže většina porovnání ID funguje správně.
Občas je nutné udělat konverzi mezi jaderným ID a UID nebo GID v konkrétním jmenném prostoru. Nejsnazším příkladem je systémové volání jako getuid(); mělo by vrátit ID specifické pro daný kontejner, nikoliv pro jaderné ID. Pro tyto konverze existuje sada funkcí:
kuid_t make_kuid(struct user_namespace *from, uid_t uid); uid_t from_kuid(struct user_namespace *to, kuid_t kuid); uid_t from_kuid_munged(struct user_namespace *to, kuid_t kuid); bool kuid_has_mapping(struct user_namespace *ns, kuid_t uid);
(Obdobná sada existuje samozřejmě i pro GID.) Konverze mezi jaderným ID a ID v rámci uživatelského prostoru vyžaduje používání mapování uloženého v jmenném prostoru, takže při používání je třeba dodat informaci o tom, o který jmenný prostor se má jednat. V případě kódu, který se spouští v kontextu procesu, stačí pro získání ukazatele na jmenný prostor zavolat current_user_ns(). make_kuid() převede UID z jmenného prostoru na jaderné ID a from_kuid() udělá zase opak. Pokud mezi ID není žádné mapování, funkce vrátí -1; v případech, kdy je nutné vrátit platné ID, volání from_kuid_munged)) vrátí speciální hodnotu „neznámého uživatele“. Jestli je mapování dostupné, se dá zjistit pomocí funkce kuid_has_mapping.
Nastavení samotného mapování musí udělat administrátor, který pravděpodobně vymezí rozsah ID pro kontejner. Patch kvůli tomu přidává do /proc/pid/ několik souborů; nastavení mapování je jen otázkou zapsání jedné nebo více množin tří čísel do /proc/pid/uid_map:
first-ns-id first-target-id count
first-ns-id je první platné UID v daném jmenném prostoru. Pravděpodobně to bude nula – ID roota je ve jmenném prostoru platné a neškodné. Toto první ID bude mapováno na first-target-id definované v nadřazeném jmenném prostoru a count je počet následujících ID, která v budou součástí mapování. Pokud se použije struktura několika úrovní jmenných prostorů, může vzniknout několik vrstev mapování, ale ty budou zploštěny mapovacím kódem, který si pamatuje jen přímé mapování z a na jaderné ID.
Vytváření mapování rozhodně musí být privilegovanou operací, takže proces, který je chce vytvořit, musí mít nastavenou capability CAP_SETUID. Proces běžící jako root v rámci svého jmenného prostoru může tuto capability mít, i když nemá k okolním prostorům přístup. Takže procesy v uživatelském jmenném prostoru si mohou sestavit vlastní podprostory s libovolnými mapováními – ale tato mapování mohou přistupovat jen k UID a GID v rodičovském prostoru. Dalším omezením je to, že mapování ID může být nastaveno jen jednou; poté už je neměnné.
Tyto mapovací funkce najdou využití na řadě míst v jádře. Jakékoliv systémové volání, které pracuje s UID a GID, musí obsahovat konverze z a do prostoru jaderných ID. Systémy souborů ext* umožňují určení UID, která mohou používat vyhrazené bloky, takže kód souborového systému musí pracovat s jadernými ID při porovnávání. Patch je tedy trochu intruzivní, ale Eric se jednoznačně snažil jeho dopad minimalizovat. Zejména se snažil o to, aby režie spojená s mapováním ID byla nejlépe nulová, pokud není v jádře podpora jmenných prostorů aktivní.
Jak říká, funkce uživatelských jmenných prostorů má řadu zajímavých vlastností:
S mou verzí jmenných prostorů se už nemusíte bát toho, že root v kontejneru zapíše do souborů v /proc nebo /sys a změní tak chování systému. Ani se nemusíte bát zpráv předávaných přes unixové sokety d-busu.
Aplikacím bez capabilities umožňuje používat vícero UID a implementovat oddělení oprávnění. Dovedu si představit, že takovéto jmenné prostory mají potenciál učinit linuxové systémy bezpečnějšími.
V době psaní tohoto textu bylo k patchi jen pár připomínek, takže nebylo jisté, jestli ostatní vývojáři s tímto zhodnocením souhlasí, nebo ne. Povaha práce na jmenných prostorech způsobuje, že dostat implementaci do jádra bude obtížné, protože vývojáři mohou mít obavy z režie a nemusí je přínosy až tak moc zajímat. Ale díky rokům úsilí se většina práce do jádra dostala tak jako tak, takže je tu šance, že se to nakonec povede i jmenným prostorům.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.