Seccomp filters funkció mostantól az Ubuntu-ban

Ubuntu

Kees Cook, az Ubuntu egykori biztonsági mérnöke, jelenleg a Google-nél a ChromeOS biztonságán dolgozó szakember, blogjában arról írt, hogy az Ubuntu Kernel Team segítségének köszönhetően az Ubuntu 12.04 LTS kernelében (a Beta 2 magasságában) felbukkant Will Drewry SECure COMPuting with filters (seccomp filters) kódja, amely hamarosan a Chrome OS-ben is megjelenik majd. Cook reméli, hogy a seccomp filters hamarosan bekerül a mainline kernelbe, és azon keresztül a többi disztribúcóba is.

A seccomp filters funkció a Berkeley Packet Filter-t (BPF) használja fel arra, hogy korlátozza a programok, alkalmazások hozzáférését a rendszerhívásokhoz. A seccomp filters használatával korlátozni lehet, hogy az egyes user space processzek mely rendszerhívásokat használhatják, így nincs szükség arra, hogy az összes rendszerhívást "láthatóvá" tegyük számukra.

A seccomp teljes dokumentációja elérhető itt. Egy tutorial a használatához itt.

( locsemege v | 2012. 03. 29., cs – 02:02 )

Erre nem lenne elég, alkalmas a SELinux? Ez egy újabb megoldás ugyanarra a problémára?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A leírás meg a tutorial alapján itt arról van szó, hogy nem "kívülről kényszeríted ki" bizonyos szolgáltatások elrejtését, hanem a program maga deklarálja (a forráskód módosítása után, a futtatható állományba beleégetve) hogy mely rendszerhívásokat szeretné használni, és mit nem. Ezzel azt éri el, hogy a programban levő esetleges sebezhetőséget nehezebb lesz kihasználni. Az, hogy ez más, mint a SELinux és társai, az világos. Az, hogy ennek van-e több értelme, vagy annak, hogy ezekhez a programokhoz megfelelő SELinux / AppArmor stb. profil készüljön, vitatható.

Igen, az nekem is feltűnt, hogy a kérdezők nem nézték meg ennek a dokumentációját.

Az, hogy ennek van-e több értelme, vagy annak, hogy ezekhez a programokhoz megfelelő SELinux / AppArmor stb. profil készüljön, vitatható.

Vagy mindkettőnek egyszerre. Jó lenne tudni, hogy mennyi erőforrást igényel a kettő együtt.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( lgb | 2012. 03. 29., cs – 17:50 )

Nekem az nem vilagos, hogy ugye egy atlag program nem fog syscall-okat hivogatni, hanem libc-t hasznal. Mi van, ha a libc-ben valtozik, hogy egy adott funkciot konkretan milyen syscall-okkal old meg? A program igy nem feltetlen tudja, hogy sajat maganak milyen syscall-okat kell engedni, foleg, ha kozben van egy libc upgrade, es ebben valtozas van. Ez elsore talan nem tunik realisztikusnak (miert hasznalna mas syscall-t?), de emlekeim szerint volt mar ilyenre pelda, hogy a libc "emulal" valamit tobb syscall-t hasznalva, aztan kesobb megjelenik egy kernel szintu jobb megoldas, sajat syscall-al erre, es a libc is atter arra (glibc marmint esetunkben).