grsecurity

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen Stribika (vitalap | szerkesztései) 2009. december 14., 04:38-kor történt szerkesztése után volt.

Tartalomjegyzék

1 Grsecurity

A Grsecurity egy biztonságot növelő Linux kernel patch. Lehetővé teszi, hogy a programok csak a működésükhöz feltétlenül szükséges jogosultságokkal rendelkezzenek, a rendszer különböző részeit jobban elkülöníti egymástól (chroot, folyamatok elrejtése), ezen kívül jó naplózási lehetőségeket is biztosít. Használható a rendszeren futó szerver alkalmazások korlátozására, shell hozzáférést biztosító szerveren a felhasználók egymástól való elszigetelésére, de akár otthoni egy felhasználós gépeken is.

1.1 Mi ellen véd?

A gépen futó programok a bennük található hibák miatt rávehetők olyan dolgokra is, amelyekre sem a fejlesztője sem a rendszer üzemeltetője nem számít, de egy támadó számára kedvező lehet. A hibás program rávehető tetszőleges kódfuttatásra, az erőforrások elhasználására, titkos információk kiadására, file-ok törlésére, módosítására. Az elsőt a külön is használható PaX modul fogja megakadályozni, a többi ellen a Grsecurity modullal védekezhatünk. Nagyon pontosan megadhatjuk, hogy egy-egy felhasználó által futtatott valamely programnak mihez van joga. A kernel memória (/dev/kmem) hozzáférhetősége is korlátozható.

Két gyakori hiba a stack buffer overflow és a heap buffer overflow. Mindkét esetben egy tömböt túlír a program, a felhasználó által megadott, vagy legalább is befolyásolható tartalommal. A különbség, hogy a stack buffer overflow esetén a stack-en van a tömb (lokális változó), a második esetben a heap-en (dinamikusan lefoglalt változó). Lehetne még az adatszegmensben is (statikus/globális változók), de az ugyanolyan, mint ha a heap-en lenne. A stack buffer overflow esetén felülírható a függvények visszatérési címe, így a végrehajtás ott folytatódik, ahol a támadó akarja. Heap buffer overflow esetén a visszatérési címekhez nem lehet hozzáférni, de függvény-pointerekhez igen, például C++ programok esetén az objektumok elején gyakran van egy virtuális metódus tábla pointer, amit lecserélve a támadó által kiválasztott függvények fognak meghívódni az eredetiek helyett.

1.2 PaX

A PaX a tetszőleges kódfuttatást próbálja megakadályozni. Az egyes képességei kapcsolhatók a bináris ELF file-ok fejlécében, és az RBAC policy file-jában is. Ez utóbbi módszer célszerűbb a rendszeren csomagkezelőből telepített programoknál, hogy frissítéskor ne vesszenek el a beállítások, az előbbi pedig az egyetlen lehetőség az egyszerű felhasználók programjainál. Ha van policy és header beállítás is, akkor a policy érvényesül.

1.2.1 Nem futtatható memória

A nem futtatható memória (NOEXEC) célja, hogy megakadályozza új futtatható kód bejuttatását egy folyamat címterébe. Két módon lehet új futtatható kódot bejuttatni: új végrehajtható memória terület létrehozása vagy egy meglévő futtatható memória terület módosítása. Az első lehetőséggel a PaX nem foglalkozik, ez a Grsecurity access control részének a feladata.

A PaX nem futtathatóvá tesz minden olyan memória területet, amelynél a futtathatóságra nincs szükség. Ilyen a stack, a heap és az ELF file-ok nem kódot tartalmazó részei. Az mprotect() és mmap() függvényt is korlátozza a rendszer: ha egy memória terület egyszer már volt írható, akkor nem lehet többet futtathatóvá tenni, ha pedig futtatható, nem lehet írhatóvá tenni.

Egyes programoknak szüksége van futás időben generált kódra. Egy gyakori példája ennek a gcc-vel fordított egymásba ágyazott függvényeket tartalmazó program. Ilyen programokban biztosítani kell, hogy a belső függvény láthassa a külső függvény lokális változóit, ezért egy paraméterben át kell neki adni egy, a külső függvény stack területére mutató pointert. Ha a belső függvényt egy függvény pointeren keresztül hívjuk, akkor a függvény memóra címe nem azonosítja egyértelműen a függvényt, nem lehet tudni, hogy melyik stack pointert kell neki átadni.

Legyen például az külső függvény fk() a belső függvény fb(). Az fb() függvény pointer csak annyi információt hordoz, hogy hol található a memóriában az fb()-hez tartozó kód. Ahhoz, hogy fb()-t meghívhassuk, szükség van a stack területre mutató pointerre is. Ha fk() nem közvetlenül hívja fb()-t, hanem például egy másik függvénynek átadja az fb() pointerét, amely később meghívja, akkor nem egyértelmű, hogy melyik stack frame-re van szükség. Ha fk() közvetlenül hívja fb()-t, akkor ez a probléma nem áll fent, mindig a legfelső stack frame-re lesz a jó.

   void call(void (*f)()) {
       f();
   }
   int fk(int x) {
       int y = x * x;
       void fb() {
           printf("y = %d\n", y);
       }
       call(fb);
       if (x)
           return x * fk(x - 1);
       else
           return 1;
   }

A fenti példaprogram ezt mutatja. Az fk() függvény kiszámolja egy szám faktoriálisát, és közben négyzetszámokat is kiír.

Az ilyen esetekben, mikor egy belső függvény címét képezzük, egy kis segéd függvény generálódik a stack-en, amely meghívja a belső függvényt a megfelelő stack pointerrel, és ennek a címe lesz a belső függvényre mutató pointer értéke. A trampoilne emuláció (EMUTRAMP[1]) a futtatható és írható memóriának ezt az egy különleges esetét engedélyezi.

Egyéb programoknak is kellhet írható és futtatható memória, ilyenek például az egyre népszerűbb just in time compilerek. Ezek működéséhez sajnos le kell tiltani a PAGEEXEC/SEGMEXEC feature-ket.

Az olyan CPU-kon, ahol a memória lapok megjelölhetők nem végrehajthatóként (NX bit), a védelem egyszerűen megvalósítható. Az olyan CPU-kon, ahol nincs NX bit (ilyen az IA-32, más néven i386), két kerülő megoldás létezik.

A PAGEEXEC[2] a nem futtatható lapokhoz nem ad user módú hozzáférést, majd amikor egy folyamat mégis megpróbál hozzáférni, a laphiba kezelő eldönti, hogy adatot vagy utasítást próbál betölteni. Ha utasítást (a hibát okozó utasítás címe megegyezik a hiba címével), akkor a taszkot leállítja, ha adatot, akkor ideiglenesen engedélyezi az user módú hozzáférést. A másik megoldás a SEGMEXEC[3]. Ilyenkor két egyforma szegmensre osztjuk a folyamatok címterét, az adat betöltésre használt félben minden adat szerepel, az utasítás betöltésre használt félből kihagyjuk a nem futtatható területeket, így ha egy nem végrehajtható területről utasítást próbálunk betölteni, laphibát történik.

1.2.2 ASLR

Nem mindig kell a támadónak új futtatható kódot bejuttatni a címtérbe, előfordulhat, hogy az is jó, ami már ott van. Ha képes felülírni a stack-en egy függvény visszatérési címét, átugorhat egy olyan kód területre, aminek futtatása számára kedvező lehet. A leggyakoribb célpont a libc, mert az mindig be van töltve, és hasznos függvényeket tartalmaz (például a system(), amivel egy program indítható). Ezt a fajta támadást return-to-libc-nek vagy return-orientált programozásnak nevezik.

Ennek végrehajtásához a támadónak tudnia kell, hogy hol találja a libc-t (vagy bármely más célpontot). Address Space Layout Randomization nélkül könnyű dolga van, mert mindig ugyanott. Az ASLR véletlenszerű helyre teszi az mmap() függvénnyel betöltött file-okat (ebbe beletartoznak a megosztott függvénykönyvtárak és maga a programkód is), a malloc()-cal lefoglalt heap területeket (RANDMMAP) és az execve() által létrehozott stack-et (RANDUSTACK) is. A kernel stack helye is véletlenszerű lesz (RANDKSTACK).

Nem minden ELF futtatható file van arra felkészítve, hogy tetszőleges helyre legyen betöltve. Az ET_EXEC típusú file-ok tartalmazhatnak abszolút címeket is. Ezért a RANDEXEC nevű feature két helyre tölti be az ilyen file-okat: a szokásos helyre nem futtathatóként megjelölve, és egy véletlenszerű helyre futtathatóként. Ha egy abszolút ugrással a szokásos helyre próbál ugrani a program, akkor a laphiba kezelő megnézi, hogy nincs-e valamelyik visszatérési cím a stack-en átírva úgy, hogy a szokásos helyre mutasson, és ha nincs, átirányítja a megfelelő helyre.

1.2.3 Egyéb

A PaX képes a felszabadított memória kinullázására. Ezzel megakadályozza a memóriában tárolt érzékeny adatok (kulcsok, memóriacímek) kiszivárgását, kb 3% lassulás árán.

A kernel néhány adatstruktúrája referencia számlálót használ, egy fajta szemétgyűjtésre. Ezek a referencia számlálók túlcsordulás esetén egy használatban lévő objektum felszabadítását idéznék elő, amihez később hozzáférve gyakran kihasználható hiba történik. Ezt a PaX megakadályozza: a túlcsordult számlálójú objektumok soha nem lesznek felszabadítva.

1.3 RBAC

A Role Based Acces Control három fontos fogalmat használ: A role a felhasználókat és a csoportokat helyettesíti, a subject egy futtatható file, az object pedig valamilyen erőforrás (file, port, stb.) amihez hozzá lehet férni. Mindig, amikor egy adott role által elindított subject hozzá akar férni egy objecthez, a rendszer ellenőrzi, hogy a szabályok alapján megteheti-e.

1.3.1 A policy file szerkezete

A policy file egy egyszerű szöveges file /etc/grsec/policy helyen.

role <role1> <rolemode>
<role attributes>
    subject / <subject mode>
    <subject attributes>
        / <object mode>
        <extra objects>
        <capability rules>
        <IP ACLs>
        <resource restrictions>
    subject <extra subject> <subject mode>
    <subject attributes>
        / <object mode>
        <extra objects>
     ...
role <role2> <rolemode>
...

1.3.2 Role-ok

A role-okhoz tartozik egy szabály gyűjtemény, amely bizonyos meghatározott esetben érvényes. Vannak user role-ok, group role-ok, egy alapértelmezett role, és speciális role-ok. A role_transitions attribútummal lehet szabályozni, hogy melyik role-ok válthatnak mire. A role_allow_ip attribútummal azt lehet megadni, hogy egy role honnan léphet be.

1.3.2.1 User role-ok

A user role-ok akkor lépnek életbe, amikor a role nevével egyező felhasználó elindít egy programot, vagy egy prorgam az ő UID-jére vált. A role nevének meg kell egyeznie egy felhasználó nevével.

1.3.2.2 Group role-ok

A user role-okhoz hasonlóan a group role akkor érvényesül, amikor egy, a role nevével egyező csoportba tartozó felhasználó indít el egy programot, vagy egy program a csoport GID-jére vált. A role nevének meg kell egyeznie egy csoport nevével. A kiegészítő csoport tagságok nem számítanak.

1.3.2.3 Alapértelmezett role

Ha sem user role-t, sem group role-t nem lehet illeszteni egy folyamathoz, akkor arra az alapértelmezett role vonatkozik. Az alapértelmezett role neve default. Érdemes mindent letiltani neki.

1.3.2.4 Speciális role-ok

A speciális role-ok használatával képesek a felhasználók olyan jogosultságokat megszerezni, amikre nincs mindig szükségük. Érdemes létrehozni egy admin role-t, amely írhatja a konfigurációs file-okat, használhatja a csomagkazelőt, stb. Az egyszerű felhasználók számára is létre lehet hozni például egy a home könyvtárhoz read-only és egy read-write jogokkal rendelkező role-t. A speciális role-ok igényelhetnek autentikációt, jelszó megadásával, vagy PAM-mal, de ez nem kötelező.

1.3.3 Subject-ek

Egy subject egy rendszeren futó folyamat jogait adja meg. A folyamatot a futtatható file-al lehet azonosítani, amiből elindult. Az egyes folyamatok elrejthetők (h, v), megvédhetők killelés ellen (p, k), stb.

Ha egy könyvtárnevet adunk meg a subject neveként, akkor a jogait minden ebben a könyvtárban lévő subject örökölni fogja.

Megadható, hogy egy subject változtathat-e felhasználót (user_transition_allow, user_transition_deny), vagy csoportot (group_transition_allow, group_transition_deny). Az alábbi példában a su programnak engedélyezzük, hogy a root felhasználóra váltson, de nem engedélyezzük, hogy a foo felhasználóra, vagy a bar csoportra váltson.

role default
    subject /bin/su
    user_transition_allow root a b c
    group_transition_allow root users
    user_transition_deny foo
    group_transition_deny bar
role root u
    subject /bin/su
    user_transition_deny foo
    group_transition_deny bar


1.3.4 Object-ek

Az object olyan dolog, amihez hozzá lehet férni. Lehet file, socket, capability vagy erőforrás.

1.3.4.1 File-ok

Megadható, egy elérési úton található file-hoz egy subject-nek milyen jogai vannak. Ez a megszokott rwx mellett lehetőséget ad pontosabb beállításokra is. Beállítható például, hogy egy file-t csak append módban lehessen megnyitni (a, napló file-oknál hasznos), vagy hogy egy file egyáltalán ne is látszódjon (h, ilyenkor is kiderülhet a létezése, mert nem lehet ugyanolyan nevű file-t létrehozni). Külön szabályozható a file-ok létrehozása (c) és törlése (d), nem következik a könytárra engedélyezett írási jogból. Korlátozható a hardlinkek létrehozása (l) is. Hátránya ennek a megközelítésnek, hogy egy egyszerű felhasználó nem rejtheti el egyes file-jait, mert az erre vonatkozó beállítások egy általa nem írható file-ban vannak.

Ha a jogokat egy könyvtárra adjuk meg, akkor minden, ami benne van, örökli ezeket. Természetesen ha van egy másik szabály egy alkönyvtárra, akkor az lesz érvényes. Fontos, hogy a subject öröklődést úgy kell tekinteni, mintha minden file object szabály itt is meg lenne adva. Például az alábbi esetben a /bin/bar-nak van írási joga a /foo/bar/baz file-hoz.

role foo
    subject /
        /            r
        /foo/bar/baz rw
    subject /bin/bar
        /foo/bar     r

A file object nevekben használhatók vadkártyák is, de ezekre nem érvényesül az, hogy a speciálisabb szabály felülírja az általánosabbat. Egyszerűen az első egyező szabály fog érvényesülni. Például az alábbi esetben a foo-val kezdődő könyvtárak sem fognak látszani.

role foo
    subject /
        /home/*    h
        /home/foo* rw

Ez azért van, mert nem lehet eldönteni, hogy a /foo/b*r/xyz* vagy a /foo/ba*r/xy* az általánosabb.

1.3.4.2 Socketek

Korlátozható, hogy egy subject melyik hostok melyik portokjaira kapcsolódhat (connect), illetve mely portokon fogadhat kapcsolatokat (bind). Teljesen le is tiltható (disabled) a kapcsolatok kezdeményezése vagy fogadása. A socket korlátozások nem öröklődnek.

<IP cím vagy hoszt név>/<netmask>:<port> <socket típusok> <protokollok>

Lehetséges socket típusok: any_sock, raw_sock, rdm, ip, dgram, stream. A lehetséges protokollok a /etc/protocols file-ban vannak felsorolva, tipikusan tcp vagy udp.

Az alábbi példában az apache a 80-as porton fogadhat TCP kapcsolatot, és nem kezdeményezhet kapcsolatot, az ssh pedig csak helyi hálózaton használható, és a DNS szervert érheti el:

subject /usr/bin/apache2
    bind    0.0.0.0:80 stream tcp
    connect disabled
subject /usr/bin/ssh
    bind    disabled
    connect 192.168.0.0/24:22 stream tcp
    connect dns.foo.hu:53     dgram  udp

Megadható port tartomány és fordított policy is, a következő példában a wine fogadhat kapcsolatot a 6111-6119 (starcraft) portokon, a firefox pedig nem kapcsolódhat a foo.bar.com-ra.

subject /usr/bin/wine
    bind 0.0.0.0:6111-6119 any_sock any_proto
subject /usr/bin/firefox
    bind    disabled
    connect ! foo.bar.com:80 stream tcp

1.3.4.3 PaX flag-ek

Megadható, hogy mely PaX feature-k legyenek bekapcsolva egy folyamat számára. Az itt megadott beállítások felülírják a bináris fejlécben megadottakat. +PAX_<flag név> vagy -PAX_<flag név> formában lehet őket megadni.

1.3.4.4 Capability-k

Szabályozhtók a capability-k a +CAP_<név> és -CAP_<név> szabályokkal. Ilyen esetben a teljes subject öröklési lánc számít. A rendszer a legáltalánosabb subjecttől elindulva halad. Például az alábbi esetben a su-nak van SETUID és SETGID capability-je, nincs NET_BIND_SERVICE capability-je, és minden más is le van tiltva (ALL).

subject /
    -CAP_ALL
    +CAP_NET_BIND_SERVICE
subject /bin
    -CAP_NET_BIND_SERVICE
subject /bin/su
    +CAP_SETUID
    +CAP_SETGID

1.3.4.5 Erőforrások

Minden Linux RLIMIT erőforrás korlátozható, csak át vannak nevezve RLIMIT_*-ról RES_*-ra. Célszerű a korlátozott subjecteknek nem adni CAP_SYS_RESOURCE-t. A szabály a következőképpen néz ki:

RES_<név> <soft limit> <hard limit>

Az alábbi példában a /bin/foo alapértelmezésként legfeljebb 10 szálat indíthat, de a saját limitjét 16-ig megemelheti.

subject /bin/foo
    -CAP_SYS_RESOURCE
    RES_NPROC 10 16

1.3.5 Tanulás

A Grsecurity RBAC rendszer egyik legnagyobb előnye, hogy a policy file-t nem kell teljesen kézzel elkészíteni, a rendszer képes tanulni. Ilyenkor figyeli, hogy az egyes folyamatok mihez férnek hozzá normál működés közben, és ebből előállít egy olyan policy file-t, ami csak ezeket engedélyezi. A tanuló módot külön engedélyezni kell, ez megtehető a teljes rendszerre (gradm -F), egy role-ra (l) vagy egy subject-re (l). A fejlesztők szerint az eredmény biztonságosabb lesz, mint ha kézzel készülne a policy file.

1.3.5.1 Konfiguráció

A /etc/grsec/learn_config file-ban megadható, hogy hogyan tanuljon a rendszer. A file egy egyszerű szöveges file, a sorok szerkezete:

<parancs> <elérési út>

A parancsok a következők lehetnek:

  • inherit-learn: A megadott elérési úthoz tartozó folyamat megtanult hozzáféréseit egy új, az adott elérési úthoz tartozó subject-hez teszi be.
  • no-learn: Az út által meghatározott folyamatot nem korlátozza és nem naplózza a rendszer.
  • inherit-no-learn: A fenti kettő kombinációja.
  • high-reduce-path: A megadott könyvtár minél nagyobb részéhez próbál hozzáférést adni.
  • dont-reduce-path: A megadott könyvtárhoz nem ad teljes hozzáférést.
  • always-reduce-path: A megadott könyvtárhoz teljes hozzáférést ad.
  • protected-path: Minden folyamat, ami a megadott file-hoz hozzáfér, külön subject-et kap.
  • high-protected-path: Mint a protected-path, csak mindenki más elől el is van rejtve.

1.3.5.2 Rendszerszintű tanulás

A rendszerszintű tanulás bekapcsolható a

gradm -F -L /etc/grsec/learning.logs

paranccsal. Ez bekapcsolja az RBAC rendszert és minden hozzáférési kísérletet naplóz a /etc/grsec/learning.logs file-ba. Ezután rendeltetésszerűen kell használni a rendszert egy ideig. Fontos, hogy a szükséges dolgokat többszöt végezzük el, mert egy könyvtárhoz csak akkor kapunk hozzáférést, ha abban legalább négy file-hoz szükségünk volt rá. Ne végezzünk adminisztrációs feladatokat, amíg a tanulás be van kapcsolva, csak ha előtte átváltottunk admin role-ra.

gradm -a admin

Végül, ha már elegendő log összegyűlt kapcsoljuk ki az RBAC rendszert,

gradm -D

és generáljuk le a policy file-t.

gradm -F -L /etc/grsec/learning.logs -O /etc/grsec/policy

1.3.5.3 Role-szintű vagy subject-szintű tanulás

A role vagy a subject neve után az "l" betűvel engedélyezhező a tanulás. Ezután a

gradm -L /etc/grsec/learning.logs -E

parancsal indítható a naplózás. Végül a rendszerszintű tanuláshoz hasonlóan lehet policy-t generálni a logokból:

gradm -L /etc/grsec/learning.logs -O /etc/policy

1.4 TPE

Egyes megbízhatatlan felhasználóknak nem lenne jó megengedni, hogy tetszőleges, akár általuk fordított programokat futtassanak. A Trusted Path Execution azt jelenti, hogy csak a root könyvtáraiban csak a root által írható file-ok futtathatók. Ezt valódi felhasználóra nem célszerű bekapcsolni, de a szolgáltatások felhasználóira igen. A TPE bekapcsolható rendszerszinten, kivéve egy csoportnak, bekapcsolható csak egy csoportnak, és role-onként is szabályozható az RBAC-cal (T role mód).

1.5 Chroot védelem

Az alap Linux kernellel a chroot nem használható programok elszigetelésére, mert könnyen ki lehet belőle törni. Egy elterjedt módszer a következő:

  1. Hozzunk létre egy ideiglenes könyvtárat a munka könyvtárban. (mkdir())
  2. Nyissuk meg a munka könyvtárat. (open())
  3. Chrootoljunk be az ideiglenes könyvtárba. (chroot())
  4. Lépjünk be a korábban megnyitott könyvtárba, ez már az új chroot-on kívül van. (fchdir())
  5. Lépjünk sokszor egy szinttel feljebb. (chdir())
  6. Chrootoljunk a jelenlegi munka könyvtárba.(chroot())

Ezt a módszert több Grsecurity feature is lehetetlenné teszi. Először is nem lehet chrootból kichrootolni. A chroothoz hasonló pivot_root() függvénnyel sem használható.

Ha a chrootolt programnak vannak nyitott file leírói a chrooton kívülről, ki tud lépni egy egyszerű fchdir() hívással. A Grsecurity ezt is letiltja, valamint minden chroot() után egy chdir("/") is végrehajtódik, hogy ne lehessen a korábbi munka könyvtár file-jaihoz sem hozzáférni.

Más szabadulási módszerek ellen is védve vagyunk. Alább látható az összes lehtséges korlátozás. Ezek a sysctl interfészen keresztül szabályozhatóak, de csak rendszerszinten, chroot-onként nem. Célszerű minden korlátozást bekapcsolni, ha ez nem zavarja a chroot-olt programokat.

1.5.1 chroot_caps

A chroot-on belül csökkenti a root capability-eit úgy, hogy a következőket megakadályozza:

  • kernel modult betölés
  • I/O eszközökhöz közvetlen hozzáférése
  • a rendszer újraindítása
  • immutable file-okat módosítása
  • más felhasználóhoz tartozó IPC erőforrások módosítása
  • rendszeridő megváltoztatása

1.5.2 chroot_deny_chmod

A chroot-on belül nem lehet chmod-dal, vagy fchmod-dal setuid-os vagy sgid-es file-okat létrehozni.

1.5.3 chroot_deny_chroot

A chroot-ból nem lehet kichrootolni.

1.5.4 chroot_deny_fchdir

A chroot-ból nem lehet fchdir-rel kilépni, akkor sem, ha van a folyamatnak külső file leírója.

1.5.5 chroot_deny_mknod

A chroot-on belül nem lehet mknod-ot használni.

1.5.6 chroot_deny_mount

A chroot-on belül nem lehet mountolni.

1.5.7 chroot_deny_pivot

A chroot-on belül nem lehet pivot_root-ot használni.

1.5.8 chroot_deny_shmat

A chroot-on belül nem lehet kívül létrehozott megosztott memóriát használni.

1.5.9 chroot_deny_sysctl

A chroot-on belül nem lehet a sysctl interfészt használni.

1.5.10 chroot_deny_unix

A chroot-on belül nem lehet olyan filerendszertől független unix domain socket-hez csatlakozni, amit a szerver a chroot-on kívülről nyitott meg.

1.5.11 chroot_enforce_chdir

A chroot után azonnal végrehajtódik egy chdir("/") is.

1.5.12 chroot_findtask

A chroot-on belül nem láthatók a külső folyamatok. Nem lehet nekik kill, vagy más signalt küldeni sem. Nem lehet őket ptrace-el debuggolni sem.

1.5.13 chroot_restrict_nice

A chroot-on belül nem lehet belső folyamatok prioritását megemelni, és külső folyamatok prioritását megváltoztatni.

1.6 Naplózás

A Grsecurity számtalan esemény naplózására képes. Ezek közül a két leghasznosabb a signal naplózás, illetve a policy megsértésének naplózása. Az előbbiből látható, hogy egy program signal hatására leállt, akkor is, ha nem terminálból futott. Az utóbbival felderíthető, hogy egy program mely file-okhoz próbál hozzáférni. Ez főleg zárt forrású, vagy rosszul dokumentált programoknál segíthet.

Vigyázni kell a naplózás beállításával, mert könnyen kezelhetetlen mennyiségű logot generálhatunk, amelyek akár érzékeny információkat is tartalmazhatnak. A naplózási lehetőségek állíthatóak kernel fordításkor, sysctl-el rendszerszinten, megadható egy csoport, akiket naplózni akarunk, és a policy file-ban az egyes file-okhoz való hozzáférés naplózását külön is szabályozhatjuk.

Az összegyűjtött naplók tájékoztathatnak egy sikertelen, vagy részben sikeres támadásról. Néhány érdekes naplóüzenet a közelmúltból:

2009-10-19 02:32:02 | grsec    | kernel  |     | alert    |
(user0000:U:/usr/lib64/mozilla-firefox/firefox)
denied execution of /bin/bash by /usr/lib64/mozilla-firefox/firefox[firefox:21607]
uid/euid:1000/1000 gid/egid:100/100,
parent /usr/lib64/mozilla-firefox/firefox[firefox:20734] uid/euid:1000/1000 gid/egid:100/100

Milyen jó oka lehet a firefoxnak bash futtatásra?

2009-10-19 15:20:44 | grsec    | kernel  |     | alert    |
(tor:U:/usr/bin/tor)
denied connect() to 173.105.219.122 port 25 sock type stream protocol tcp by /usr/bin/tor[tor:2212]
uid/euid:106/106 gid/egid:1016/1016,
parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

Természetesen a konfig file-ban le van tiltva a 25-ös port.

2009-10-24 14:05:01 | grsec    | kernel  |     | alert    |
(users:G:/)
denied access to hidden file /boot by /usr/bin/ktorrent[ktorrent:6234]
uid/euid:1003/1003 gid/egid:100/100,
parent /bin/bash[bash:5860] uid/euid:1003/1003 gid/egid:100/100

Csak nem új kernelt töltünk le?

1.7 Adminisztráció

1.7.1 gradm

gradm -E RBAC bekapcsolása
gradm -D RBAC kikapcsolása
gradm -R RBAC polixcy file újratöltése
gradm -S RBAC állapotának lekérdezése
gradm [-F] -L /etc/grsec/learning.logs Tanulás bekapcsolása
gradm [-F] -L /tc/grsec/learning.logs -O /etc/grsec/policy Policy file generálása a tanultakból
gradm -n role1 Váltás jelszó nélküli role-ra
gradm -a role2 Váltás jelszavas role-ra.

1.7.2 paxctl

A paxctl programmal állíthatóak át az egyes programok PaX beállításai. Ezek a beállítások a bináris file-ok fejlécében vannak tárolva. Ha ez a fejléc nem létezik, vagy egy régebbi formátumban van, akkor létre kell hozni (paxctl -C), vagy át kell konvertálni (paxctl -c).

P PAGEEXEC Lap alapú nem futtatható memória
E EMUTRAMP Trampoline emuláció
M MPROTECT Mprotect korlátozások
R RANDMMAP Véletlenszerű mmap memóriacímek
X RANDEXEC Végrehajtható file-ok betöltése véletlenszerű helyre
S SEGMEXEC Szegmens alapú nem végrehajtható memória

Egy adott tulajdonság mindig a nagy betűvel kapcsolható be és a kis betűvel kapcsolható ki.

1.7.3 pspax

Az éppen futó folyamatok PaX információit írja ki.

1.7.4 execstack

A stack végrehajthatóságát lehet vele letiltani vagy engedélyezni egy bináris file-on. Hasonlóan a paxctl-el állítható jellemzőkhöz, ez is a file-ban van tárolva.

  • Letiltás: --clear-execstack
  • Engedélyezés: --set-execstack
  • Lekérdezés: --query

1.7.5 sysctl interface

Majdnem az összes Grsecurity feature kapcsolható a sysctl segítségével. Ezek a kernel.grsecurity részben találhatók. Közülük a legfontosabb a kernel.grsecurity.grsec_lock. Ha ezt 1-re állítjuk, akkor ezentúl egyetlen kernel.grsecurity.* változót sem módosíthatnunk. Ezt célszerű a valamelyik init scriptbe beletenni, ha már kipróbáltuk, hogy miket lehet bekapcsolni.

1.8 Források

Személyes eszközök