grsecurity
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ó.
1.2 PaX
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
Az 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 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.4 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
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.
1.5 Chroot védelem
1.6 Naplózás
1.7 Egyéb
1.8 Adminisztráció
1.8.1 gradm
1.8.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.8.3 pspax
Az éppen futó folyamatok PaX információit írja ki.
1.8.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.8.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.