Az SE Linux projekt bejelentette az SE Android elérhetőségét, melynek célja, hogy az SELinux által megvalósított Mandatory Access Controlt Androidon is elérhetővé tegye.
Miért van erre szükség? Mindenek előtt fontosnak tartom megjegyezni, hogy az átlagos Android felhasználók biztonságára a legnagyobb veszélyt még mindig saját ostobaságuk jelenti, a legtöbb Marketen elérhető malware ugyanis egyszerűen elkéri a számára szükséges jogosultságokat, amit rendszerint meg is kap.
Ezen semmilyen szoftver nem fog tudni segíteni, de vannak tisztán technológiai problémák is, melyeken jó lenne mielőbb úrrá lenni:
Egyrészt sajnos a felhasználók mellett a fejlesztők sem mindig biztonságtudatosak. A Skype androidos kiadásában például mindenki számára olvasható fájlban kerültek eltárolásra a felhasználók adatai, így bármely más alkalmazás ki tudta olvasni azokat. Ha a fájlhozzáférések korlátozásának felelősségét az app fejlesztő helyett a felhasználó kezébe adjuk, egy jó alapértelmezett szabályrendszerrel az ilyen jellegű problémák elkerülhetővé válnak.
Mélyebben fekvő tervezési hiányosságokra világított rá Anthony Lineberry a DEFCON 18-on tartott előadásában. Ezeknek egy különösen figyelemre méltó halmaza épít az Andorid különböző IPC lehetőségeire, melyek kihasználásával például egy hálózati hozzáférést nem igénylő alkalmazás kinzézhet az internetre a böngészőn keresztül. Az alábbi videó demonstrálja a problémát egy távoli shell nyitásával:
A problémák harmadik osztályát a különböző kernel-sebezhetőségek jelentik, melyekkel szemben sajnos az SE Android sem tud teljes körű védelmet nyújtani, az alkalmazások és a rendszerkomponensek hatékonyabb elválasztásával viszont a támadók mozgástere jelentősen csökkenthető.
Ezek alapján az SE Android egyelőre a paranoiásabb kockák játékszere lehet, nem tartom azonban kizártnak, hogy a jövőben az apptelepítési kultúra illetve az Android Market szűrési mechanizmusainak fejlődésével - ami a szofisztikáltabb támadások megjelenését fogja eredményezni - szélesebb körben is szükségessé válhat a hardening megoldás telepítése, de hasonló megoldásra igény mutatkozhat vállalati környezetben is.
EQ · http://rycon.hu 2012.01.07. 19:10:35
buherator · http://buhera.blog.hu 2012.01.07. 20:06:40
EQ · http://rycon.hu 2012.01.07. 20:08:47
buherator · http://buhera.blog.hu 2012.01.07. 20:16:36
ghost_____ 2012.01.07. 21:35:29
Hunger 2012.01.07. 22:22:41
buherator · http://buhera.blog.hu 2012.01.07. 22:29:48
Hunger 2012.01.07. 22:47:44
buherator · http://buhera.blog.hu 2012.01.07. 23:15:11
Hunger 2012.01.08. 02:51:44
"aki nem a lefektetett új alapelvek szerint építkezik ezután, az egy dinoszaurusz".
Ezt gondolom én is. A PaX 12 éve lefektette az alapelveket (NX, ASLR, MPROTECT, etc.), amelyek közül néhányat azóta már átvettek a nagyok is. Akik viszont nem, azok menthetetlenül lemaradtak...
Ez a kernel self-protection téma ennek ellenére még mindig annyira új és előremutató, hogy sokan nem értik meg a lényegét. Elméletben az új kód új hibákat hozhat be a kernelbe valóban, viszont ebben az esetben az új kód egy magasabb szintre viszi a kernel önmaga biztonságát, a kontrollt és ezáltal az egész rendszer egyenszilárdságát azzal, hogy a továbbiakban a kernel sem tehet meg már bármit, az "ő mindenhatóságát" is korlátozza.
Érdemes elgondolkozni azon is, hogy ezt a userspaceben már úgyahogy máshol is bevezetett funkciót, mint az NX a kernelspaceben még mindig egyedül csak a PaX valósítja meg rendesen. Nincs sehol máshol a kernelben teljes W^X és annak korlátozása sincs máshol, hogy az adatlapokat csak úgy ne lehessen futtathatóvá tenni (kernelben való triviális ROP elleni védelem).
Az olyan megoldásokról, amelyek komplett hibaosztályok kihasználását és exploit technikák családját teszik lehetetlenné (mint pl. a REFCOUNT, USERCOPY és UDEREF) már nem is beszélve. Ezek több garanciát és próaktívan nagyobb biztonságot hoznak a rendszerbe, mint amennyi kockázatot rejtenek az új kódokkal behozott potenciális hibák.
buherator · http://buhera.blog.hu 2012.01.08. 12:45:23
"minden új kód, elméletileg a grsec maga is bevezethet új hibákat a kernelbe"
Ha ezt objektÍv módon (pl. valamilyen metrikával, matematikailag) meg tudod cáfolni, vagy akár meg tudod mutatni, hogy egy ilyen cáfolat egyáltalán létezhet, akkor hajrá!
(Btw én magam is ellene vagyok annak, hogy az ilyen kérdéseket ennyire absztraháljuk, ilyen értelemben most az ördög ügyvédjét játszom)
A grsec/PaX áldásos hatásairól, jelentőségéről szóló eszmefuttatásaidnak pedig nagyon szívesen szentelek akár több önálló posztot, szerintem sokakat érdekelne.
Hunger 2012.01.08. 16:16:43
"a grsec maga is bevezethet új hibákat a kernelbe"
buherator · http://buhera.blog.hu 2012.01.08. 16:39:30
Ahogy minden új kód, elméletileg az SELinux, de akár a grsec is bevezethet új hibákat a kernelbe, bár utóbbira nagyobb szorzóval lehet fogadni a bukméker irodákban (előbbire pedig volt már precedens).
Hunger 2012.01.08. 17:33:08
"Ahogy minden új kód, elméletileg az SELinux, de akár a grsec is bevezethet új hibákat a kernelbe"
Ezzel meg ugye nem mondtál lényegében semmit, gyakorlatilag "Captain Obvious" kategória. :)
"bár utóbbira nagyobb szorzóval lehet fogadni a bukméker irodákban"
Így már érdekesebb lehet. Viszont jogossá válna a kérdés, hogy "ezt objektÍv módon (pl. valamilyen metrikával, matematikailag)" alá tudod-e támasztani. ;D
Volt egyébként már biztonsági hiba a PaX-ban is, úgyhogy mindkettőnél van precedens. A kérdés mindig az, hogy mitől félünk, mi ellen akarunk védekezni és ennek érdekében mit vállalunk cserébe. Erre mondja az angol, hogy "trade-off".
Egyébként, ha kifordítjuk a dolgot, akkor akár mondhatnánk azt is, hogy a gyakorlatban teljesen mindegy hány új hibát hoz be a grsec/PaX a kernelbe egészen addig, amíg a kernelben önmagában a hibák száma nem nulla... ;)
buherator · http://buhera.blog.hu 2012.01.08. 17:58:18
Hunger 2012.01.09. 09:03:27
BTW
selinuxproject.org/page/SEAndroid
The Android build process requires allowing executable stacks.
setsebool allow_execstack=1
lulz
ace911 2012.01.09. 13:32:46
Az android-ot szerintem azzal lehetne menteni a user által kapott túl sok jogtól, hogy a jogosultsági igényeket valóban finoman szabályozhatóvá tennék, ill. a market-re kerülő programoknál ellenőriznék az igények jogosságát. Arra gondolok pl, hogy ha egy app írni akar, akkor ne sd full access-t akarjon, hanem pl. egy adott könyvtárba írhasson/olvashasson, ugyanez a netkapcsolatra, r/o címtár stb., stb. Ha valamiért tetszik egy program és jogosultság igénye van, akkor úgyis megkapja..(miért ne?) de legalább legyen meg fejlesztőkben is a biztonságutdatosság.. ill. ha az update után jönne a rosszaság az ellen legalább védhetne.. ami még előnyös lehetne a jogosultságtól függő funkcionalitás: ha nem adok pl. net és/vagy tárcsázó jogot, akkor a jegyzettömb legyen csak egy kis vacak lokális jegyzettömb..(amiért feltettem). Mindig bennem van a para, hogy a háttérben rezdülés nélkül bármi kitárcsáz a 0690...-re vagy aktiválja a netkapcsolatot amikor nem kellene..
synapse · http://www.synsecblog.com 2012.01.25. 21:01:51