Jaderné noviny – 20. 10. 2011: Omezování systémových volání

31. 10. 2011 | Luboš Doležel | Jaderné noviny | 6963×

Aktuální verze jádra: 3.1-rc10. Citáty týdne: Neil Brown, Peter Zijlstra, Matthew Garrett. Odpovědi na některé otázky kolem účtů na kernel.org. Další jaderná implementace RAID5. Omezování systémových volání přes řídící skupiny?

Obsah

• Aktuální verze jádra: 3.1-rc10
• Citáty týdne: Neil Brown, Peter Zijlstra, Matthew Garrett
• Odpovědi na některé otázky kolem účtů na kernel.org
• Další jaderná implementace RAID5
• Omezování systémových volání přes řídící skupiny?

Aktuální verze jádra: 3.1-rc10

Aktuální vývojová verze jádra je 3.1-rc10 vydaná 17. října. Moc se toho nedělo – většinu tohoto -rc tvoří drobné aktualizace v MIPS a zbytek jsou víceméně jen drobné opravy ovladačů. Jo a ještě je tam pár oprav souborových systémů (btrfs a xfs). Konečné vydání verze 3.1 čekejte v blízké budoucnosti.

Stabilní aktualizace: verze 3.0.7 vyšla 17. října se středně velkou sadou důležitých oprav.

Citáty týdne: Neil Brown, Peter Zijlstra, Matthew Garrett

Vypadá to, že se blížíme k určité shodě... nebo alespoň já, za ostatní mluvit nemůžu

-- Neil Brown

Já říkám, že je mnohem lepší zaútočit na hlavní zdroj zla nekompromisním způsobem, než abychom se snažili vyhnout nejhorším excesům a způsobit skryté chyby.

Lidé po nějakou dobu protlačovali myšlenku, že je dobré být tolerantní v tom, co přijímáte jako vstup, a striktní v tom, co posíláte ven. Řekl bych, že si lidé začali uvědomovat, že to byla strašná chyba, protože teď dostávají naprostý humus a nikdo už neví, co je správně.

-- Peter Zijlstra

Souhlasím, že ta věc, co je potřeba udělat, bude zahrnovat webové vývojáře a pohrůžky násilím, ale mám podezření, že weboví vývojáři vznikají rychleji, než je můžeme stíhat převychovávat.

-- Matthew Garrett

Odpovědi na některé otázky kolem účtů na kernel.org

Bylo zveřejněno nové FAQ obsahující odpovědi na otázky kladené v souvislosti s procesem návratu na kernel.org. Je to zajímavé čtení pro ty, jejichž přístup ještě nebyl obnoven. V současnosti dáváme přístup pouze vývojářům, kteří předtím měli gitové repozitáře na kernel.org a tyto repozitáře byly aktivní po únoru 2011. Později zvážíme vytváření účtů pro vývojáře s neaktivními stromy nebo pro ty, kteří v minulosti účet na kernel.org neměli.

Další jaderná implementace RAID5

Jádru chybí mnoho věcí, ale implementace RAIDu to nejsou. Subsystémy MD i DM mají aktuálně úplnou podporu RAID a souborový systém Btrfs má nízkoúrovňovou podporu RAID. Podpora RAID5/6 pro Btrfs byla už párkrát zaslána, ale do hlavní řady se ještě nedostala. Takže je docela na místě přemýšlet nad tím, jestli v jádře potřebujeme další implementaci RAID5.

Další tu bude, pokud to Boazu Harroshovi projde; jeho patch pro podporu RAID5 byl zaslán na několik mailing listů o souborových systémech. Boazův patch má za cíl přidat podporu RAID5 do kódu „objektového raid enginu“ [objects raid engine] v souborovém systému exofs, který poskytuje POSIXový souborový systém nad zařízením objektového úložiště [object-storage]. Také implementuje RAID5 u backendu objektového úložiště pNFS.

Podle Boaze jeho práce představuje hezkou, obecnou RAID knihovnu, která by šla použít i na jiných místech; především, jak říká, by ji mohlo využít Btrfs. Samozřejmě by bylo ještě hezčí, kdyby se některá z jaderných implementací také přesunula k této knihovně – nebo kdyby exofs mohlo použít jednu z těchto implementací. Tato podoba podpory RAID5 může být čistší a obecnější než ty ostatní, ale dostat ji do jádra si v současnosti může žádat silnější argumenty.

Omezování systémových volání přes řídící skupiny?

Omezování systémových volání je nyní v komunitě jaderné bezpečnosti žhavým tématem. Objevilo se několik různých návrhů a téma bylo do určité hloubky diskutováno na nedávném Linux Security Summitu, ale zatím se žádné řešení nedostalo do jádra. Łukasz Sowa nedávno zaslal RFC s popisem odlišného mechanismu pro omezování systémových volání, který může mít oproti ostatním přednosti. Má ale potenciální nevýhodu, neboť používá funkci, která je u některých jaderných hackerů nepopulární: řídící skupiny.

Z hlediska konceptu je Sowův nápad dosti přímočarý. Administrátor by umístil proces nebo procesy do řídící skupiny a poté by omezil, která systémová volání mohou tyto procesy (a jejich potomci) dělat. Současné rozhraní používá čísla systémových volání, která jsou zapsána do řídících souborů syscalls.allow a syscalls.deny. Lze zakázat libovolné systémové volání, ale lze povolit pouze ta, která jsou přístupná rodičovskému procesu. Proces, který použije zakázané volání, dostane chybu ENOSYS.

Používání čísel systémových volání se zdá být docela nepohodlné (a tato čísla nejsou na všech architekturách shodná), ale nemusí být možné se tomu vyhnout. Ale jsou tu i větší problémy, například výkon. Sowa říká, že procesy v kořenové řídící skupině tráví o 5 % více času v systému, což je dost citelný postih. Jeho patch se napojuje do rychlé cesty systémových volání v assembleru, což asi neprojde. Je to také specifické pro architekturu a je to nyní implementováno jen pro x86. Paul Menage poukazuje na to, že napojení na ptrace() by mohlo některé tyto problémy odstranit:

Nemohl by ses napojit na volání ptrace? To je už implementováno na každé architektuře. Nastav příznak vlákna, který vyvolá odklonění k syscall_trace_enter(), pouze pokud je některé z volání aktuálního vlákna zakázáno, a pak se nemusíš hrabat v assembleru.

Menage zmínil i další technické problémy patche, ale je skeptický ohledně toho, jestli je vůbec třeba. Řekl bych, že většinu zranitelností lze využít jen za použití systémových volání, která potřebují aplikace pro dělání běžné práce (open, write, exec, mmap apod.), což omezuje užitečnost vypínání jen podle čísel volání. Protože tento přístup pouze umožňuje binární vypnuto / zapnuto pro řízení systémových volání, nepovažuje to za dostatečnou úroveň detailnosti nastavení. Toto kopíruje postoj Inga Molnara, který jej v roce 2009 vyjádřil v reakci na návrh na rozšíření seccompu o bitovou masku povolených systémových volání.

Ale už se objevila řada projektů, které vyjádřily zájem o flexibilnější funkci v jádře podobnou seccompu, počínaje týmem prohlížeče Chromium, který navrhl několik způsobů, jak to udělat. Seccomp nabízí řešení pro omezení procesů k užívání jen pár systémových volání (read(), write(), exit() a sigreturn()), ale to je pro mnoho projektů nedostatečně flexibilní. Ale Molnar byl vždy hlasitým odpůrcem řešení, která u používání systémových volání umožňují jen binární rozhodnutí, a preferuje mechanismus, který filtruje systémová volání za použití podmínek ve stylu ftrace. Tento přístup ale není oblíbený u některých dalších vývojářů v oblasti trasování a instrumentace.

Je to dilema. Mnoho projektů (např. QEMU, vsftpd, LXC) má o takovou funkci zájem, ale (zatím) žádná implementace neuspěla. Sowovo řešení na bázi řídících skupin může být dalším takovým. Rozhodně výkon u procesů, které nejsou ve skupině (tzn. jsou v kořenové skupině), nebude oblíbeným bodem – což je slabé slovo – ale i kdyby Menagův návrh (nebo nějaký jiný mechanismus) vedl k řešení s malým nebo žádným dopadem na výkon, mohly by se objevit stížnosti kvůli neoblíbenosti řídících skupin.

Navrhovaná diskuze o rozšíření seccompu pro blížící se Kernel Summit by mohla být nadějí, ačkoliv se nezdá, že by se dostala do agendy. Tak či tak bude přítomna řada účastníků z mailing listu. Řídící skupiny nicméně jsou v agendě, takže na toto výživné téma proběhne nějaká ta debata. O Kernel Summitu se dočtete v příštích Jaderných novinách.

       

Komentáře

[gn]

s/to přijímáte/co přijímáte/

[zulu]

Menagovo návrh

[Ferdinand]

Tenhle článek je česky.