Jaderné noviny 236

5. 11. 2003 | Robert Krátký | Jaderné noviny | 3447×

Patch podporující mnoho skupin. Oddělení hlavičkových souborů kernelu od uživatelských (sága pokračuje). Vývojáři pochybují o významu DigSig. Bezpečnostní návrh: dostupnost portů kernelu.

Do konference přišlo celkem 1670 emailů, nejvíce jich poslali Bartlomiej Zolnierkiewicz, Greg KH, Andrew Morton.

Patch podporující mnoho skupin, 22 e-mailů

Rusty Russell poslal patch, který napsal spolu s Timem Hockinem, zvyšující počet možných skupin na více než 200. Zjevně o to stáli hlavně uživatelé Samby. Rusty vysvětlil: Tato verze se zbavuje interního pole skupin (je tak často sdílené, že to ani nestojí za to - a vypadá to pak rozumněji) a v případě, že má někdo obrovské množství skupin, spoléhá na vmalloc.

Linus Torvalds odpověděl:

Proč?

kmalloc() funguje dobře. Když někdo potřebuje 200 skupin, možná je ještě normální, ale pokud někdo potřebuje víc než se se vejde do kmalloc(), je to tak přehnané, že už k tomu není důvod.

vmalloc prostor je omezený a kód tak bude hodně nehezký.

Díval jsi se poslední dobou na zdrojové kódy glibc nebo proč myslíš, že bychom měli podporovat uhozené používání?

Pete Zaitcev z Red Hatu řekl, že jejich společnost ve skutečnosti má zákazníky, kteří mají uhozené počty skupin s pomocí vlastních patchů. Z nějakého důvodu je to oblíbené mezi lidmi kolem projektu Beowulf. Měl bych poznamenat, že to není moc rozšířené.

Tim Hockin řekl, že i jeho společnost má zákazníky, kteří chtějí více skupin než zvládá kmalloc. Poslal svůj vlastní patch, který se Linusovi líbil trochu víc, ale stále nesouhlasil s podporou tisíců skupin. Tim na tom ještě pracoval a poskytl patch oproti 2.6.0-test6 spolu s popisem všech funkcí.

Linus odpověděl, že ho mrzí to neustálé stěžování, ale tentokrát kritizoval duplikaci kódu. Navrhl možné řešení, ale když Tim některé věci upravil a poslal patch s dalším popisem vlastností, nikdo už neodpověděl.

Oddělení hlavičkových souborů kernelu od uživatelských (sága pokračuje), 16 e-mailů

Navazujíc na (nebo ignurujíc) Jaderné noviny 232 řekl Andries Brouwer:

Už dlouhou dobu mluvíme o oddělení hlavičkových souborů kernelu od částí, které se více hodí pro začlenění do uživatelského prostoru.

Je to rozsáhlý projekt a zabere mnoho času, zvláště pokud chceme, aby uživatelské hlavičky pěkně vypadaly - místo obyčejného zkopírování všeho, co najdeme ve stávajících hlavičkách.

Někde se musí začít a úplně prvním krokem je ujištění, že s projektem souhlasíte. Následuje výběr názvů adresářů.

Níže

1. malý textový soubor "linuxabi" popisující názvy (podadresáře include linuxabi a linuxabi-alpha, atd.),
2. soubor linuxabi/mountflags.h s definicemi pro MS_RDONLY a příbuzné,
3. soubor linux/mountflags.h, který obsahuje linuxabi/mountflags.h a kromě toho definuje věci jako MS_RMT_MASK a IS_NOATIME(inode) a
4. patch pro fs.h, který tyto definice odstraňuje a přidává řádku include.

Obsah jeho souboru linuxabi:

Podadresáře linuxabi a linuxabi-$ARCH (linuxabi-alpha, linuxabi-arm, ...) v linux/include jsou určeny pro hlavičky, které mají být používány jak kernelem, tak v uživ. prostoru. Symbolický odkaz linuxabi-arch ukazuje na linuxabi-$ARCH pro aktuální architekturu.

...

J.A. Magallon navrhl pojmenovat soubor 'abi' místo 'linuxabi', aby mohly i jiné systémy, jako třeba BSD, dodržovat stejnou konvenci.

Na jiném místě Eric W. Biederman prohlásil, že ta celá věc patří do 2.7, ale Andries nesouhlasil. Řekl, že restrukturalizace se vůbec nedotýká vývoje kernelu, ale Eric trval na tom, že by ke správné implementaci bylo potřeba celého vývojového cyklu.

Nikdo nezmínil práci, kterou již dříve udělal Matthew Wilcox.

Vývojáři pochybují o významu DigSig, 15 e-mailů

Pavel Machek řekl, že pokud chci něco spustit, mohu se exec() syscall vyhnout a provést mmaps ručně... Makan Pourzandi odpověděl:

Protože existuje mnoho různých scénářů útoků, je na tuto otázku i více možných odpovědí. Beru v potaz ten nejreálnější a poskytnu stručnou odpověď.

Makan poskytl tři důvody, proč si myslí, že DigSig ztíží útočníkovi práci: 1) pomáhá omezovat přístup k systému zrušením exekuce cizího kódu, 2) může zabránit spuštění kódu, který umožňuje download rootkitu a 3) není možné spustit nepodepsaný kód, takže by si útočník musel kód zkompilovat na napadeném stroji.

Poslední, ale myslím, že nejdůležitější věcí je, že úroveň obtížnosti provedení takového útoku je o mnoho vyšší než běžná úroveň znalostí mnoha script kiddies. Naprostá většina útočníků má malé nebo vůbec žádné znalosti o operačních systémech všeobecně a o Linuxu především, zvlášť pokud mluvíme o napsání C programu, zavolání mmaps v tom programu a spuštění kódu, který zajistí práva roota a pak odstranění toho modulu ke spuštění klasického útoku.

Neexistuje 100% bezpečný systém, ale DigSig zvyšuje úroveň bezpečnosti, protože prostě útočníkovi ztěžuje jeho/její útok.

O pár zpráv dále Alexander Viro poznamenal, že DigSig může mít na 'script kiddies' dočasný vliv, ale během měsíce dojde k aktualizaci rootkitů a budeme zase na začátku, jen tu bude navíc zaclánět další patch...

Willy Tarreau a Pavel s tím souhlasili. Poblíž dodal Valdis Kletnieks: DigSig zabezpečuje jen jednu malinkou cestičku, kterou by se mohl dostat spustitelný kód do paměti.

Bezpečnostní návrh: dostupnost portů kernelu, 8 e-mailů

John Lange navrhl:

Proč existuje požadavek, aby se k nižším portům (pod 1024) mohly připojit pouze root procesy?

Já tomu rozumím tak, že je to přežitek z dávných dnů, kdy se jednalo o bezpečnostní funkci. Protože na portech pod 1024 mohly naslouchat jen root procesy, mohli jste "důvěřovat" tomu, že každé spojení na nízkým port bude "bezpečné". Jinými slovy, nikdo, kdo neměl root přístup nemohl na telnetovém portu "blufovat", takže bylo bezpečné napsat své heslo.

Nevím, jestli je to skutečný důvod, ale pokud ano, zcela zjevně už to nemá smysl, coby "bezpečnostní" funkce.

Kromě toho, nevytváří teď ten požadavek větší bezpečnostní problém než jaký kdy vyřešil?

Procesy nucené běžet jako root (přinejmenším při startu systému), které mají bezpečnostní díry, jsou přeci hlavní příčinou "vzdálených root exploitů".

Takže neslouží-li ten požadavek na roota pro nízké porty žádnému účelu a navíc je příčinou bezpečnostních problémů, není na čase se ho zbavit?

Kromě toho, zatímco pouze root může vázat na nízké porty, KAŽDÝ uživatel může vázat na vysoké porty. To také způsobuje spoustu bezpečnostních starostí.

Takže bych rád navrhl následující zlepšení bezpečnosti kernelu a rád bych slyšel vaše komentáře.

Návrh: Bezpečnostní systém vázání portů založený na skupinách pro příchozí a odchozí vázání.

Například skupina "root" může naslouchat na portech "*" (všechny) a zároveň má povolena odchozí spojení na "*" (všechny).

Skupina "www" by mohla vázat na porty "80, 443" (http, https) a neměla by povolena ŽÁDNÁ odchozí spojení.

Skupina "mail" (nebo postfix nebo co já vím) by mohla naslouchat na portu "25" (smtp) a připojit se k "25".

Skupina "users" by mohla naslouchat na všech, ale připojit se jen k 20-21, 80, 443.

atd.

To zařídí dvě zásadní věci:

• Žádný proces nebude muset běžet jako root.
• Žádný neautorizovaný proces nebude smět naslouchat nebo vytvářet připojení k portu. Na serverech, které povolují vzdálené uživatele, to zabrání věcem jako jsou boty, relay spamu, shození ftp a mnohému druhu neplech.

Představuji si jednoduchý soubor "/etc/ports" ve formátu "<groupid>,<incoming ports>,<outgoing ports>".

Uvědomuji si, že podobné věci je možné udělat jinými způsoby (myslím, že s iptables), ale řekl bych, že by to měla být základní součást bezpečnosti systému, a proto by to mělo být rovnou v kernelu (stejně tak, jako je teď vázání roota na nízké porty).

Valdis Kletnieks řekl, že Johnův návrh už je napsaný: grsecurity patch. Na jiném místě řekl také James Morris, že podobná funkce je implementována v AccessFS. Ale James dodal: Standardní chování bychom měli v hlavním kernelu ponechat jako výchozí. Další bezpečnostní modely mohou být implementovány pomocí LSM, Netfilteru, konfiguračních voleb atd. John považoval za dobré znamení, že jiní už implementovali různé verze jeho nápadu a řekl Jamesovi:

Myslím si, že existuje několik závažných důvodů, proč bychom měli standardní chování změnit.

• Patche nejsou řešení. Jako sysadmin si nemůžu dovolit extra problémy s aplikováním patchů kdykoliv je třeba upgradovat kernel. Navíc, objeví-li se urgentní patch pro jádro, musel bych čekat na externí patch, abych mohl kernel zkompilovat. Takže obecně jsou pro běžné sysadminy patche problematické.
• Není-li funkce zabudována do standardního chování, nebude pro ní nikdo psát kód.
;
• Pokud se shodneme, že stávající chování je zastaralé a způsobuje problémy s bezpečností, musíme se ptát "Existuje rozumný důvod ho zachovávat?". Nebude Linux s patchem lepším, bezpečnějším Linuxem?

Zpětná kompatibilita by taky nebyla problém, protože většina programů prostě zkusí zabrat port a když ho nedostanou, vyhodí chybou. S myšlenkou /etc/ports by fungovaly.

Všechny ostatní programy, které by mohly mít potíže (například ty, které kontrolují, jestli jsou root, před tím, než se spustí), mohou být stále spouštěny jako root.

Jesse Pollard řekl, že kompatibilita pro portování aplikací bude potíž. Navrhl místo toho řešení založené na LSM modulu, který by mohl požadavky na porty předávat bezpečnostnímu démonu, a přidělovat/odmítat alokaci portů podle externích pravidel. Bylo by to více flexibilní, snadněji spravovatelné a méně by to zasahovalo do kernelu.

V originálu Kernel Traffic 236 vyšla navíc ještě tato témata:

• Linux 2.4.23-pre6 Released
• Big Updates To HFS+ And HFS
• New Xen Virtual Machine Monitor For x86

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licencí GPL verze 2.

       

Komentáře