Kernel

Az LKML-en a Linux kernel biztonságáról szóló thread-ben felbukkant a védekezés lehetséges eszközeként a magyar Molnár Ingo által fejlesztett exec-shield (tapasztalatok) és a szintén magyar (titokzatos) pipacs által kódolt PaX.A beszélgetésben sok mindenről esett szó. Linus ismét kijelentette, hogy nem nagyon szeretné a mainline kernelben látni az ilyen típusú biztonsági patcheket. Ezen kívül elmondta, hogy senki ne számítson arra, hogy valaha is lesz olyan, hogy a kernelben 0 hiba van. A fejlesztők megteszik a tőlük telhető legjobbat, de akinek teljes biztonság kell, az használjon kiegészítő patcheket, mint például az Exec-shield.

Ebből aztán egy nagy flame lett. John Richard Moser a PaX-ot javasolta az exec-shield helyett. Molnár Ingo és Arjan van de Ven, a Red Hat munkatársai pedig az általuk fejlesztett foltot találták jobbnak. Ingo leírta, hogy szerinte milyen hiányosságai vannak a PaX-nak, míg Moser az exec-shield gyengeségeit elemezte.

A KernelTrap összeszedte a hosszú flame leglényegesebb leveleit itt.

Marcelo pár órával ezelőtt kiadta a végleges 2.4.29-es Linux kernelt. A 2.4.29 nem más, mint a 2.4.29-rc4 változtatás nélkül kiadott verziója.

A változások listája Marcelo levelében.

FUSE: Filerendszer a felhasználói térben

Andrew Morton tegnap kiadta a 2.6.11-rc1-es kernel első -mm patchét. Az patch egyik újdonsága a FUSE. Ami miatt megakadt rajta a szemem elsősorban az, hogy meglehetősen magyaros volt a szerző neve. Korábban is láttam már a FUSE-t különböző fórumokon, de most, hogy esély van arra, hogy a mainline kernel része legyen jobban felkeltette az érdeklődésemet.

A FUSE szerzője Miklos Szeredi, aki tulajdonképpen Szeredi Miklós és hazánkfia. Mivel keveset tudtam a FUSE-ről úgy gondoltam, hogy a legegyszerűbb az lesz, ha közvetlenül a szerzőt kérdezem vele kapcsolatban. Ma délután írtam egy levelet, és Miklós pár órán belül válaszolt is.

Nézzük mi az a FUSE:``Láttam, hogy a FUSE beolvasztásra került a 2.6.11-rc1-mm1 kernelbe. Pár kérdésem lenne a FUSE-val kapcsolatban, de nem igazán találtam választ rájuk sem a http://www.szeredi.hu-n, sem a http://fuse.sourceforge.net/-en. Remélem, Tőled választ kapok a kérdéseimre :-)

Amennyit én tudok a FUSE-ről, az a következő:

A FUSE (Filesystem in USErspace) segítségével képesek vagyunk felhasználói térben filerendszert megvalósítani. A FUSE kommunikációs felülete egyszerű, hatékony, biztonságos és emellett támogatja a szokásos filerendszer szemantikákat.

Eredetileg az AVFS projekthez készült, de önálló projektté nőtte ki magát. A megszületése óta számos felhasználói térben megvalósított filerendszer használja a már FUSE-t.

Szóval a kérdések:''

trey: A klasszikus filerendszerek általában kernel térben vannak megvalósítva. Mi célból implementál valaki filerendszert a felhasználói térbe (user space)?

Szeredi Miklós: A kernel programozás több szempontból nehezebb, mint a közönséges (user space) programok írása. Például egy hiba a filerendszerünkben akár az egész rendszer stabilitására kihathat. Nehezebb nyomonkövetni a kernel futását, és a C nyelven kívül más nem használható. Ezek a
hátrányok mind nincsenek, ha userspace-ben valósítjuk meg a filerendszerünket.

Persze vannak hátulütői is a userspace megoldásnak: például
valamelyest lassul a file műveletek sebessége.

trey: Milyen lehetőségek vannak a FUSE-ban a felhasználók szemszögéből? Magyarul mire lehet felhasználni?

Szeredi Miklós: Van mindenféle: titkosított filerendszerek, a GMail-t mint tárhelyet kihasználó filerendszer, van amelyik Siemens telefonok adatait teszi elérhetővé, stb...

trey: Milyen korlátai vannak a FUSE-nak? Mi az amire a FUSE nem használható, és amire a kernel space filrendszereket kell használni?

Szeredi Miklós: Jelenleg a FUSE nem támogatja a memória meppelés (mmap) egy fajtáját (konkrétan shared writable mapping-et). Ezt azonban csak nagyon kevés, speciális program használja. Előbb utóbb majd felmerül az igény, hogy ez is működjön, de egyelőre nélkülözni kell.

Amúgy a határvonal nem ilyen éles. Vannak filerendszerek amik sokkal hatékonyabban megvalósíthatók kernelben (ilyenek a hagyományos, diszk alapú filerendszerek), és vannak amiket sokkal könnyebb userspace-ben megírni (pl. egy zip file-okat kezelő filerendszer)

trey: Mennyire stabil a FUSE? Használható már akár éles környezetben is?

Szeredi Miklós: Attól függ mennyire éles. Atomreaktorok vezérlésére például nem ajánlanám. Amúgy viszonylag stabil. Persze hibák mindig vannak és lesznek is. Jelenleg a legstabilabb verzió az 1.4-es, de ez már elég régi és sok minden hiányzik belőle. A legújabb a 2.2-pre3, ebben
azért még találunk problémákat.

trey: Miben más a FUSE, mit például a LUFS, amelynek első ránézésre hasonló a szerepe?

Szeredi Miklós: Valóban nagyon hasonló a két rendszer. A "lufis" névre hallgató kis programocska (FUSE honlapjáról letölthető) segítségével akár egy LUFS filerendszert is lehet FUSE kernellel futtatni.

A legfőbb különbség a filerendszerek futtatási környezetében rejlik. A LUFS filerendszerek dinamikus könyvtár (shared object) formájúak, miket egy keretprogram tölt be és hív meg minden egyes műveletre.

A FUSE esetén a filerendszer maga egy futtatható program, ami azonban használ egy könyvtárat (libfuse) a kernellel való kommunikáció megkönnyítésére.

trey: Olvastam a filerendszerek közt egy SMB for FUSE névre hallgató FS-ről. A leírása azt mondja, hogy hogy az SMB for FUSE-val probléma nélkül böngészhetem a (windows) hálózatot úgy, mintha az a saját filerendszeremen lenne. Körülbelül ezt tudom megvalósítani a kernel-beli smbfs és smbmount felhasználásával is. Miért jobb nekem, ha ezt a FUSE segítségével valósítom meg?

Szeredi Miklós: Pontosan nem tudom, mivel még nem probáltam (szerencsére nagyon keveset kell Windows környezettel érintkeznem). De valahogy úgy képzelem, hogy az SMB for FUSE a hálózaton található gépek feltérképezését könnyíti meg.

trey: Hiányoltam a filerendszerek közül az SSH-n vagy FTP-n keresztüli távoli filerendszerek mount-olásának lehetőségét (mint például a LUFS SSHFS vagy FTPFS). Ilyen létezik a FUSE-hoz is?

Szeredi Miklós: Egyrészt lehet a fent említett "lufis" megoldást alkalmazni. Ez azonban kicsit nehézkes, és már van natív SSHFS (FUSE honlapjáról letölthető, és 2.2-es FUSE verziót igényel).

trey: Miért pont FUSE a neve? Ha jól tudom, ezen a néven fut már másik projekt is?

Szeredi Miklós: Nagyon okos kis rövidítés: Filesystem in USErspace. De a névválasztás nem az erősségem, és ez a név már sok fejfájást okozott.

Köszönöm szépen Szeredi Miklósnak a gyors válaszokat. Mint Miklós írta, ez volt az első interjúja, így külön örömmel tölt el, hogy a HUP kérdezhette először...

A FUSE-val egyébként a napokban foglakozott a KernelTrap is itt.

Chris Wright a korábbi beszélgetés hatására összeállította a Linux kernel biztonsági hibáit majdan kezelő kapcsolattartó ``működésének'' vázlatát.

A vázlatban az áll, hogy a Linux kernel fejlesztői nagyon komolyan veszik a biztonságot. Ennek megfelelően ha valaki biztonsági hibát talál, arról szeretnének (időben) tudni, hogy azokat javíthassák, és publikálhassák olyan gyorsan, ahogy az csak lehetséges.

A vázlat szerint ezt az alábbi módon szeretnék végrehajtani:1) Kapcsolattartó

Lesz egy kapcsolattartó. A kapcsolattartó a $CONTACTADDR. Ez nem más, mint egy zártkörű levelezési lista, amelynek a tagjai a biztonsági tisztek (Security Officers). Az Ő feladatuk, hogy a bejelentéseket megvizsgálják, szükség esetén a javításokat kifejlesszék, majd kiadják a fixeket. Az elképzelhető, hogy a biztonsági tisztek extra segítséget kérjenek az alrendszerek karbantartóitól ahhoz, hogy a hibát megértsék és a javítást el tudják készíteni.

Kívánatos lenne ha a bejelentéseket a kapcsolattartó $PUBKEY kulcsával titkosítva tennék meg a bejelentők.

Minél több információt biztosítanak a bejelentők, annál könnyebben és gyorsabban lehet a hibákat javítani. Bármilyen működő exploit kódok nagyon hasznosak a javítás kifejlesztéséhez. A biztonsági tisztek semmilyen exploitot nem publikálnak a bejelentő beleegyezése nélkül, kivéve ha az már publikus.

2) Bejelentés

A kernel biztonsági kontakt célja, hogy együttműködjön a bug bejelentőjével a hiba kijavításában és elvégezze a bejelentést (disclosure). A kernel biztonsági kontakt a hiba teljes közzétételét támogatja olyan gyorsan, ahogy az csak lehetséges. Ésszerű a bejelentés késleltetése abban az esetben, ha a hiba vagy a javítás nem teljes egészében ismert / megértett, a javítás nincs teljes egészében kész vagy a gyártók koordinációjára még szükség van. A késleltetési időt az illetékesek rövidre tervezik, amelyek napokban és nem hetekben, hónapokban mérhetők majd. Az teljes bejelentés alapértelmezett késleltetése $NUMDAYS.

Durván ennyi a javaslat.

Születtek még egyéb javaslatok is. Például Florian Weimer szerint a 3. pontnak érdemes lenne felvenni egy NDA-ra vonatkozó kitételt. Alan Cox szerint megfontolandó lenne egy a https://bugs.kernel.org-on működtetett Bugzilla is. Alan szerint a $NUMDAYS késleltetés mértékét még meg kell vitatni, de szerinte a 14 napos időkeret megfelelő lehetne.

További hozzászólások a thread-ben.

Han Boetes azon mesterkedik, hogy Propolice támogatást ad a Linux kernelhez. A Propolice egy az IBM (Hiroaki Etoh) által kifejlesztett gcc (GNU Compiler Collection) kiterjesztés, amely védelmet ígér a stack manipulációs támadások ellen.

A C-ben írt programok az elégtelen programozói ismeretek vagy hanyagság miatt gyakran szenvednek olyan hibákban, amelyek puffer túlcsordulásos (buffer overflow) támadásokhoz nyújtanak támadási felületet. A Propolice az ilyen támadásokat próbálja meg detektálni és a változók újrarendezésével védelmet próbál nyújtani a mutatók (pointers) manipulálása ellen. A Propolice védelem a fordításkor kerül az alkalmazásokba, ezért a használatához az összes védendő alkalmazást újra kell fordítani. Az OpenBSD már jó ideje használja a Propolice-t (1, 2). Han Boetes egy levelet írt az LKML-re amelyben kifejtette, hogy szerinte a legtöbb Linux kernel hiba a puffer túlcsordulásos hibák közé tartozik. Hasznos lenne, ha a Linux kernelt le lehetne fordítani Propolice támogatással, mert szerinte a Propolice használatával az összes buffer overflow hiba DoS támadássá mérséklődhet a PP használata esetén. Ezért arra kéri a fejlesztőket, hogy fogadjanak el egy olyan patchet, amely lehetővé teszi a Linux kernel lefordítását PP támogatással (természetesen patchelt gcc esetén).

A fejlesztők több dologban sem értettek egyet Han-nel. Arjan van de Ven szerint a Linux kernel hibák nagy része nem buffer overflow hiba. Feltette a kérdést, hogy Han szerint mit nyernénk a PP-vel a Linux kernelben. Arjan szerint a PP alkalmazása sokkal inkább az userland-ben lenne érdekes. Andi Kleen egyetértett Arjan-nel, szerinte is nagyon ritkák a bof típusú hibák a Linux kernelben. Urlich Drepper szerint a Propolice gcc patchek meglehetősen a instabilak.

Mindenesetre született patch a 2.6.9-hez, aki úgy érzi, hogy kipróbálná, az megtalálja a foltot a thread-ben.

A mai napon egy új kernelfát jelentett be az LKML-en egy fejlesztő. Andres Salomon célja az -as fával az, hogy a gyártóknak, disztribútoroknak egy stabil, biztonságos kernel alapot adjon. Az elképzelés a következő: az -as kernelfa biztonsági és bugfixeket fog egybefogni különböző forrásokból. A fejlesztő nem fog foglalkozni driver frissítésekkel, nagy alrendeszer frissítésekkel, kódtisztítással, csakis kizárólag biztonsági problémákra kíván megoldást nyújtani.Mint a fejlesztő írta, azokat a patcheket szedte össze, amelyeket a 2.6.10.1-es kernelben látott volna szívesen. Az első patch 34 hibára nyújt megoldást a 2.6.10-es kernelhez, köztük a do_brk(), a grsecurity és PaXTeam által jelentett hibák, vagy éppen a tegnap említett SMP race hibákhoz.

A patch megtalálható a következő helyen:

http://www.acm.rpi.edu/~dilinger/patches/2.6.10/as1/

Változások listája itt.

02e412361955fa80c0ea3a5a59a37c36 ChangeLog

0a75d0e8922491fb2540b3c6178dfd58 linux-2.6.10-as1.tar.gz

540effd229ea72dad4bd274bba40fb94 patch-2.6.10-as1.gz

patch-2.6.10-as1.gz - patch a vanilla 2.6.10 kernelhez

linux-2.6.10-as1.tar.gz -a patchek külön-külön szétválasztva

A patchek a BitKeeper-ből lettek ``kihúzva'', így igazából a ``hivatalosak'', Andres csak az összegyűjtő szerepet vállalta magára.

Andres bejelentése itt.

Marcelo kiadta a 2.4.29-es kernel második kiadásra jelölt verzióját. A patch-ben már javítva van - más egyebek közt - a tegnap említett SMP versenyhelyzet hiba.

Chris Wright ma egy érdekes thread-et indított az LKML-en...

Ismert, hogy az elmúlt napokban felbukkant néhány olyan Linux kernelt érintő biztonsági hiba, amelynek a javítása a felfedezők szerint elkésett, mégpedig abból az okból, hogy az illetékesek nem válaszoltak megkeresésükre.Chris Wright azt a kérdést tette fel a Linux kernel levelezési listán, hogy lenne-e valakinek ellenvetése az ellen, ha létrehozna egy biztonsági kontaktot abból a célból, hogy a biztonsági hibákat bejelenteni kívánóknak legyen hova fordulniuk.

Jelenleg a biztonsági hibák bejelentése a következő fórumokon / személyeken keresztül történik: 1.) LKML, 2.) karbantartók, 3.) vendor-sec

Chris szerint sokkal jobb lenne, ha egy központosított helyen történnének a bejelentések. Chris a következőkkel javasolja kibővíteni a jelenlegi MAINTAINERS filet:

+SECURITY CONTACT

+P: Security Officers

+M: kernel-security@{vger.kernel.org, osdl.org, wherever}

+S: Supported

+

A levelére hamarosan válaszolt Linus is, aki nem zárkózik el a dologtól. A nemrég indult thread itt. Ha valakinek ötlete van, akkor az MOST KELL ELMONDANI!

Öt nap elteltével újabb Linux kernelt érintő biztonsági hibáról adott ki advistory-t Paul Starzetz az iSEC Security Research bogárvadásza.