Portál AbcLinuxu, 5. května 2025 09:15
Aktuální verze jádra: 3.16-rc3. Citáty týdne: Borislav Petkov. Capsicum pro Linux.
Aktuální vývojová verze jádra je 3.16-rc3 vydaná 29. června.
Stabilní aktualizace: verze 3.15.2, 3.14.9, 3.10.45 a 3.4.95 vyšly 26. června, následovány byly verzemi 3.15.3, 3.14.10, 3.10.46 a 3.4.96, a to 30. června.
Jo jo, světový pohár člověku s pracným laděním hodně pomůže.
Capsicum je framework pro sandboxování procesů, který byl původně vyvinut pro FreeBSD; na LWN se o něm psalo před dvěma lety. David Drysdale nyní zaslal počáteční podporu pro Capsicum pro Linux k revidování; to představuje dobrou příležitost k tomu se podívat, jak tento mechanismus zapadne do linuxového jádra. Může být dost těžké přesvědčit jadernou komunitu, aby jej přijala, ale funkčnost, kterou Capsicum nabízí, za to možná stojí.
Capsicum staví na konceptu pojmenovaném „capabilities“ (schopnosti), které jsou naprosto odlišné od capabilities v Linuxu (stejně jako od těch POSIXových). Ve světě Capsicum se capabilities týkají popisovačů souborů, na kterých omezují, jaké operace je možné nad nimi provádět. Pokud je tedy přítomna capability CAP_READ, pak je možné na popisovači pouze číst. Přístup k lseek() je řízen pomocí CAP_SEEK, mapování do paměti má také sadu svých capabilities (například CAP_MMAP_W pro zapisovatelné mapování), zkracování souborů je řízeno pomocí CAP_FTRUNCATE a tak dále. Pro ioctl() a fcntl() jsou dále k dispozici dvě speciální capabilities omezující podpovely těchto dvou volání.
Ve výchozím stavu nejsou popisovače omezovány. Při běžném používání proces sám sebe omezí pomocí systémového volání cap_rights_limit():
int cap_rights_limit(unsigned int fd, struct cap_rights *new_rights, unsigned int new_fcntls, int nioctls, unsigned int *new_ioctls);
Po tomto volání budou operace na fd omezeny na ty, které jsou uvedeny v new_rights. Pokud v těchto právech bude CAP_FCNTL, pak new_fcntls omezí povely, které jsou dostupné ve fcntl(). Stejně tak když je mezi capabilities uvedeno CAP_IOCTL, pak pole new_ioctls (o délce nioctls) předává sadu povolených příkazů pro ioctl(). Nad stejným popisovačem je možné udělat více volání cap_rights_limit(), ale capabilities je možné jen odebírat, nikdy ne přidávat.
K dispozici je i volání cap_rights_get(), pomocí kterého je možné se dotázat na capabilities přiřazené k danému popisovači.
Není snad ani potřeba dodávat, že omezení popisovačů by nebyla moc užitečná, pokud by omezený proces mohl snadno otevřít nové popisovače na ty samé objekty. Aby se tak nemohlo dít, Capsicum nabízí „režim capabilities“, do něhož se vstupuje pomocí cap_enter(). Jakmile proces do tohoto režimu vstoupí, přistup k většině globálních jmenných prostorů je omezen, čímž se zabraňuje otevření nových souborů. Proces stále může otevřít soubor pomocí openat(), pokud má popisovač na příslušný adresář (a samozřejmě i potřebné capabilities). Takto lze ale přistupovat jen k souborům pod tímto adresářem – používání absolutních cest nebo „../“ není dovoleno.
(Dodejme, že „přístup jen k souborům pod tímto adresářem“ je funkčnost natolik zajímavá, že ji David přesunul do odděleného patche a zpřístupnil ji i bez Capsicum. Tento patch přidává příznak O_BENEATH_ONLY pro volání jako openat(). Pokud je adresář otevřen s touto vobnou, pak lze výsledný popisovač používat jen k otevírání souborů umístěných v hierarchii systému souborů pod tímto adresářem.)
Nutno podotknout, že aktuálně zaslaný patch ještě nenabízí implementaci cap_enter(). Schází také celý mechanismus „capabilities nad procesy“, který vyjadřuje konkrétní procesy jako popisovače, aby bylo možné řídit související systémová volání (wait(), kill() apod.). Patch je popsaný jako „1. část“, takže se dá čekat, že to zbývající přijde později.
V jádře implementace systémových volání obvykle začínají převodem předaných popisovačů na struct file pomocí volání fdget(). Právě v tomto bodě se David rozhodl aplikovat kontrolu capabilities. Jakmile jsou popisovače omezovány pomocí Capsicum, pak je běžná struktura file nahrazena obalující strukturou obsahující informace o právech. Každé volání fdget() v jádře (je jich cca. 100) musí být nahrazeno voláním:
struct file *fdgetr(unsigned int fd, int caps ...);
Kde caps je výčet (o variabilní délce) capabilities, které musejí být přítomny, aby volání uspělo. Volající funkce také musejí být upraveny tak, aby počítaly s návratovou hodnotou „chyba vyjádřená v ukazateli“; v aktuálních jádrech fdget() může vrátit NULL, ale ne už konkrétní chybovou hlášku. Výsledkem je to, že patch je poněkud invazivní; to může být příčinou odporu v případě, že se patch dostane do stavu, kdy se bude vážně uvažovat o jeho začlenění.
Patch nyní funguje tak, že vytváří dvojici háčků Linuxových bezpečnostních modulů (LSM; Linux Security Module), které provádějí samotnou kontrolu capabilities. David ale přemýšlí, jestli je toto správný přístup, neboť Capsicum není kompletním bezpečnostním modulem. Pokud by jádro implementovalo stohování bezpečnostních modulů, pak by Capsicum mohlo běžet v tomto režimu spolu s jiným, úplnějším modulem. Zatím to ale nevypadá, že by stohování bylo v jádře implementováno v dohledné době. Proto bude možná lepší, pokud bude Capsicum implementováno mimo framework LSM.
Je tu pak další věc na zvážení. Jaderný subsystém pro bezpečné výpočty (seccomp; secure computing) umožňuje načítání programů (napsaných pro virtuální stroj BPF), které teoreticky mohou implementovat všechna omezení nabízená v Capsicum, hlavně tedy jestliže budou začleněny nedávno navržené změny v BPF. Nemusí to být snadné, ale mělo by to být možné. Někdo se tedy jistě zeptá, jestli jádro potřebuje další mechanismus pro vytváření sandboxů s podobnými schopnostmi.
Přidání nových subsystémů souvisejících s bezpečností může být obtížné prosadit; mnoho vývojářů vidí v těchto náročných subsystémech jen malý přínos. Omezit škody, které může napáchat kompromitovaný proces, ale má význam a to, že FreeBSD již Capsicum používá, znamená, že některé aplikace již mají potřebný kód. Přidání stejného API do Linuxu by umožnilo opětovné použití této práce. Proto stojí Capsicum za zvážení, i když to bude pravděpodobně znamenat překonávání překážek, než se začlenění stane skutečností.
Kvízová otázka: co znamená zkratka "MS" v nadpisu stránky? V češtině se jako oficiální název - přinejmenším v kolektivních sportech - tradičně používá "mistrovství světa" nebo "mistrovství Evropy", i když v některých případech (třeba fotbal nebo hokej) doslovný překlad oficiálního anglického názvu zní jinak. A používají ho i oficiální orgány (ČAFR, ČSLH, …).
Termín "světový pohár" se samozřejmě používá také, ale pro označení jiných soutěží. Obvykle se jedná o celosezónní soutěže, do kterých se započítávají výsledky jednotlivých závodů. Namátkou třeba světový pohár cyklokrosařů nebo lyžařů (běžců i sjezdařů).
neznamenalo, že se to nedá přeložit jako světový pohár
Přeložit se dá ledacos, třeba "General Attorney" jako "generál Attorney" (abych použil hodně proslavený příklad). Jenže takový násilný překlad místo zavedeného termínu je dobrý nanejvýš ke zmatení nepřítele - a čtenář by neměl být považován za nepřítele. :-)
Kvízová otázka: co znamená zkratka "MS" v nadpisu stránky?Když něco hledám, používám ctrl+F ;).
Termín "světový pohár" se samozřejmě používá také, ale pro označení jiných soutěží.To jsem tak nějak očekával, když jsem se ptal, jestli to máš čím podložit. Ale jestli se něčemu v angličtině říká stejně (world cup) a v češtině různě (světový pohár, mistrovství světa), tak je to docela bordel.
Přeložit se dá ledacos, třeba "General Attorney" jako "generál Attorney"Doufám, že argument absurditou uvádíš jen jako legraci.
Ale jestli se něčemu v angličtině říká stejně (world cup) a v češtině různě (světový pohár, mistrovství světa), tak je to docela bordel.
Je. Ale není to nic mimořádného, to se stává i v jiných oborech včetně IT. Třeba Němci AFAIK používají stejné slovo pro paket (packet) i balíček (package), takže se jim občas stává, že v angličtině použijí ten druhý termín.
Doufám, že argument absurditou uvádíš jen jako legraci.
Ano, ale jen do určité míry - i tenhle překlad by koneckonců v jiném kontextu mohl být správně.
argument absurditouOn-topic bonus: reductio ad absurdum/argumentum ad absurdum se v češtině říká důkaz sporem.
Nikdy jsem sport nechápal.To je v pořádku, není na tom nic, co by se mělo chápat. Staří latiníci tomu říkali „Panem et circenses“. Pokud by poddaní pochopili některé souvislosti, mohlo by to mít pro vládnoucí elitu nepříjemné následky. Je potřeba odpoutat pozornost davu pozornost někam jinam. No a zrovna fotbal tohle umí opravdu dobře.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.