Az utóbbi napokban jó nagy viharokat kavartak a Google Chrome-mal kapcsolatos biztonsági kérdések. Ma végre volt időm egy kicsit utánajárni a dolgoknak, amihez nagy segítséget nyújtott ez a doksi, amit sghctoma linkelt be egy kommentben. A másik forrás a Chrome alapján képező Chromium motor fejlesztői dokumentácója volt, amit itt találhattok meg.

Biztonsági szempontból a legfontosabb kérdés a Google böngészőjével kapcsolatban az, hogy van-e benne valami fajta sandbox eljárás megvalósítva? A válasz természetesen attól függ, hogy mit tekintünk (teljes értékű) sandboxnak. A Wikipedia azt írja:

"A számítógépes biztonság területén a sandbox egy programok biztonságos futtására használt eljárás. [...] A sandbox tipikusan az erőforrások, mint pl. a lemezen és a memóriában lévő munkaterület egy szűkre szabott halmazához enged hozzáférést a vendég folyamatok számára. A hálózati hozzáférés és a kiszolgáló fájlrendszerről illetve bemeneti eszközökrő való olvasás lehetősége általában erősen korlátozott."

Szigorú értelemben véve ezek a kritériumok a Chrome esetében nem teljesülnek maradéktalanul, mégis azt mondhatjuk, hogy a Google törekvése ezeknek az elveknek a megvalósítására igencsak figyelemre méltó a böngészők piacán.

A Chrome elveti az általánosan elterjedt, monolitikus szemléletmódot, és modulárisan épül fel. A megbízhatatlan forrásból érkező, potenciálisan veszélyes adatokat a külön folyamatként futó renderelő modulok dolgozzák fel, ezeket pedig a böngésző kernel fogja össze, amely kapcsolatot biztosít a renderelő folyamatok és az operációs rendszer által kezelt ablakkezelő és fájlrendszer között. Míg a kernel az alkalmazást indító felhasználó jogaival működik, addig a veszélyes renderelő modulok operációs rendszer szinten szigorúan korlátozott folyamatokként futnak, és ez az, ami (jó esetben) megakadályozza azt, hogy ezek a processek a böngésző kernel biztonsági mechanizmusait kikerülve működhessenek. Konkrétan a renderelő folyamatok:

• Korlátozott biztonsági tokennel
• Windows Job objektumként
• Külön asztalon (ez néhány hiányosan megírt API fv. miatt)
• Vistán pedig külön integritási szinten

futnak (Ennél a pontnál érthetővé válik, hogy miért csak Windowsra érhető el a program). Ezekkel a privilégiumokkal a megbízhatatlan kódokat futtató folyamatok gyakorlatilag semmihez nem férhetnek hozzá közvetlenül. Ugyan a Windows biztonsági mechanizmusaiban lehetnek hibák, de ez már nem a Chrome problémája :)  Azt viszont nem szabad elfelejteni, magában a böngésző kernelben is lehetnek  hibák. Ezen kívül a hivatalos dokumentáció fehívja a figyelmet néhány területre, ahol a fenti eljárások nem működnek:

• FAT fájlrendszeren nincs lehetőség ACL-ezésre, ezért az ilyen típusú köteteken (pl. pendrive) lévő fájlokat nem védik meg a korlátozott tokenek.
• Elméletileg lehetséges TCP/IP socketeket nyitni Windows 2000-en és XP-n, mivel az ehhez tartozó alacsony szintű rendszerhívások nem igényelnek megfelelő azonosítást, ám ezt a lehetőséget a Stanford kutatóinak nem sikerül kihasználniuk.
• a különböző anti-malware megoldások esetleg beszúrhatnak olyan DLL-eket a renderelő modulok folyamataiba, amelyek nem várt működést okozhatnak.

A Chrome sandboxing rendszere tehát korántsem tökéletes, ezt az elmélet és a gyakorlat is jól mutatja. Azt viszont kifejezetten szívderítő látni, hogy végre van egy böngésző, ami túl tud lépni a phishing figyelmeztetések dobálásán, és az architektúra alapjainál igekszik kezelni a biztonsági kérdéseket. Én drukkolok, hogy ez minél jobban sikerüljön!