Grsecurity doksi hiányosságból adódó kérdések

Mivel a Grsecurity doksija (http://en.wikibooks.org/wiki/Grsecurity) néhány kérdésben kétségek között hagyott, és az IRC csatornán (irc://irc.oftc.net/grsecurity) sem tudták mindet megválaszolni, úgy döntöttem, megpróbálom megválaszolni én, és ha már így teszek, felrakom a hupra. Lássuk:

After reading the "official" documentation of (http://en.wikibooks.org/wiki/Grsecurity) I was still left in doubt with some aspects of Grsecurity. I asked my questions in the corresponding IRC channel (irc://irc.oftc.net/grsecurity) but it didn't give me all the answers. So, I decided to answer them myself and publish the results at http:/hup.hu. Let's see it:

1. Hogyan töltődik be a policy a kernelbe?

Ellentétben a SELinuxszal (ahol a módosított init tölti be) és az RSBAC-kal (ahol tisztán a kernel végzi a betöltést), amelyeknél a boot processz korai, szigorúan meghatározott fázisában történik a policy betöltése, a Grsecurity-nál az userland-ben futó gradm parancs (többnyire a -E kapcsolóval) tölti be a policyt. Erre a célra alkalmas lehet egy saját System V szolgáltatás hozzáadása a /etc/init.d könyvtárhoz. Még az éles policy létrehozása előtt ugyanebben a szkriptben (tehát a boot processznek ugyanazon a pontján) érdemes elhelyezni a full system learninget végző gradm utasítást, hogy a lehető legjobban leképezze a rendszert. A fejlesztők szerint a Grsecurity RBAC-nak a boot processzben történő előbbre hozása bonyolultabb policyt, de nagyobb biztonságot, míg a későbbre tolása egyszerűbb policyt, de gyengébb biztonságot eredményez. Én úgy érzem, a helyzet nem ilyen egyszerű, és a késői RBAC inicializációra szavaznék, mert az egyszerűbb policy kevesebb engedélyt tartalmaz, tehát futás közben nagyobb biztonságot jelent, valószínűleg nem teszi lehetővé például a System V init szkriptek menet közbeni meghívását. Igaz, cserébe a boot processz során nincs RBAC védelem, de ez talán elfogadható.

1. How does the policy get loaded into the kernel?

Contrary to SELinux (in which a modified init does the job) and RSBAC (in which the kernel does it by itself) where the policy is loaded in at a strictly defined moment in the early boot process, with Grsecurity the policy is loaded by the userland command `gradm` (usually using the -E option). One could probably add an own System V inits script to the /etc/init.d directory to call gradm. This same init script (or at least the same moment during the boot process) should be the point to call gradm to generate the policy by doing full system learning, because using this way the policy will fit the system quite well. According to some opinions, a policy recorded and used at a later point of the boot process can be simpler but less secure, whereas a policy being used early in the boot process must be more complex but safer. In my humble layman's opinion the scenario may be not this simple: I vote for a policy recorded and loaded on a later point of the boot process because its fewer rules give fewer permissions to processes, probably meaning better security. A policy like this should not make possible to start or stop System V init script. It's true however, that on the other hand we wont have RBAC protection during (most of) the boot process, but it may be an acceptable risk.

2. Pontosan mi alapján kerül eldöntésre, mi lesz egy processz role-ja?

Számomra a Grsecurity RBAC egyik legszimpatikusabb tulajdonsága, hogy a subjecteket (processzek) és az objecteket (fájlok, erőforrások, POSIX capability-k, hálózati erőforrások stb.) nem ruházza fel saját magára nézve specifikus metainformációkkal, (mint a - véleményem szerint - értelmetlenül, sőt már káros módon bonyolult SELinux és RSBAC) hanem azzal dolgozik, amit már eleve is biztosít számára a Linux kernel, sőt, érzésem szerint a gyakorlatban ennek ellenére (vagy épp ezért) hatékonyabb a fent említett rendszereknél. (Arról nem is beszélve, hogy a puszta RBAC védelmen felül rendkívül sok és rendkívül hasznos, praktikus biztonsági megoldást tartalmaz).
A Grsecurity RBAC rendszere tehát elég egyszerűen dönti el, milyen user/group (vagy default) role-ba vagy domain-be kerüljön egy processz: semmi mást nem használ fel ennek eldöntésére, csak a processz RUID-jának és RGID-jének értékét. Az effective, saved és filesystem UID/GID értékek semmit sem számítanak ebből a szempontból.
A RUID-role/domain és RGID-role/domain összerendeléseket egyébként nem futásidőben nyeri ki a UNIX felhasználói adatbázisból, hanem a policy betöltésekor vagy frissítésekor betölti ezeket a kernelbe és ott tárolja. Éppen ezért a UNIX felhasználói adatbázis módosítása után esetleg szükség lehet a policy újratöltésére.

2. What is the exact method of allocating roles to processes?

One of my favourite attributes of Grsecurity RBAC is that (unlike the overwhelmingly and harmfully complex SELinux and RSBAC) it doesn't add its own specific metainformation set to subjects (processes) and objects (files, resources, capabilities, network resources, etc.). Instead of this, it just uses the information already provided by the Linux kernel. Moreover - in my opinion - despite this (or probably because of this) it can be more efficient then those mentioned systems. (No to mention that in addition to a sole RBAC protection, GRsecurity provides numerous useful and practical security solutions).
So, Grsecurity's RBAC system assigns user/group (or the default) roles or domains to processes in a quite simple way: It doesn't respect anything else but the RUID and RGID of the given process. Effective, saved and filesystem UID/GID don't matter in this relation.
RUID to role/domain and RGID to role/domain assignments aren't extracted in runtime from the UNIX user database. Instead, they are computed and loaded during policy load or refresh. This means, that it may be necessary to reload the policy after UNIX database modifications.

3. Mit jelent a "G" role mode (http://en.wikibooks.org/wiki/Grsecurity/Appendix/Role_Modes)?

Ha jól értem semmi mást, mint hogy a role kap egy implicit subjectet, ami a /sbin/gradm programnak a működését teszi lehetővé, minden bizonnyal azzal együtt, hogy ez az implicit subject megkapja az "a" mode-ot is, hogy a /dev/grsec eszközfájlon keresztül kommunikálhasson a kernelben levő Grsecurity rendszerrel. Ha jól veszem ki, az RBAC rendszer API-ja semmi másból nem áll, mint a /dev/grsec eszközből.

3. What does role mode "G" exactly mean (http://en.wikibooks.org/wiki/Grsecurity/Appendix/Role_Modes)?

If I understand it correctly, it means nothing more than giving an implicit `/sbin/gradm` subject to the role, with sufficient permissions to communicate with the kernel via the /dev/grsec character special devide file (which means setting the `a` mode for this subject). BTW, according to my experiences, the API of the in-kernel Grsec system consist of nothing more than this /dev/grsec node.

4. Milyen öröklődést gátol az "o" subject mode (http://en.wikibooks.org/wiki/Grsecurity/Appendix/Subject_Modes)?

Kétféle öröklés van a Grsecurity RBAC policy-jében: Egyrészt az ugyanabban a role-ban levő kevésbé specifikus subjectek engedélyeit örökölhetik az "alattuk levő" specifikusabb subjectek, másrészt amikor egy subject végrehajt egy olyan programfájlt, amelyhez - mint objecthez - xi hozzáférési joga van, akkor a processz az execve után nem a neki megfelelő subjectbe kerül, hanem az execve előtti subject jogait örökli. Az "o" subject mode kizárólag ez előbbi típusú öröklődés megakadályozására szolgál.

4. What kind of inheritance does subject mode "o" prevent (http://en.wikibooks.org/wiki/Grsecurity/Appendix/Subject_Modes)?

There are two distinct types of inheritance in the Grsecurity RBAC policy: On the one part more specific subjects can inherit permissions from less specific subject. On the other hand when a subject has at least "xi" permissions to an object and executes it, then Grsecurity RSBAC won't check the policy for an appropriate subject for the process upon that execve call, instead, the process will continue running with the permissions of the calling subject. Subject mode "o" prevents only the first type of inheritance.

5. Milyen mély ACL öröklődést tesz lehetővé az "i" object mode (http://en.wikibooks.org/wiki/Grsecurity/Appendix/Object_Modes), pl. változatlanok maradhatnak-e a jogosultságok RUID/RGID váltás esetén?

Amennyiben a RUID/RGID váltás role (vagy domain) váltást eredményez, akkor az "i" mode teljesen hatástalan. A processz új role-ba, és az ottani megfelelő subjectbe kerül. A roleváltást tehát nem lehet megakadályozni az "i" mode-dal, csakis a role-on belüli subjectváltást. A subjecteken keresztüli ACL öröklődés mélysége tetszőlegesen szabályozható, subjectváltás ugyanis execve-híváskor történhet, és a következő execve esetén az RBAC rendszer megnézi, hogy az aktuális (megörökölt) subject szabályai ismét öröklést írnak-e elő az "i" mode-on keresztül, és ha igen, megint öröklődés történik, ha nem akkor subjectváltás (ha kell). Az "i" mode tehát csak egyszeres mélységű öröklődést idéz elő, de újabb "i" flag-ekkel ez tetszőlegesen meghosszabbítható.

5. How deep is the inheritance caused by object mode "i"? (http://en.wikibooks.org/wiki/Grsecurity/Appendix/Object_Modes) For example, can subject ACLs be kept unchanged through RUID/RGID changes?

RUID/GUID changes triggering role (or domain) change render mode "i" ineffective. In these cases the process will be assigned new role and an appropriate subject to. This means chat role change cannot be prevented by mode "i" at all. Subject inheritance within the same role/domain can be regulated to be arbitrarily deep, since subject changes occur on execve calls, and - upon every execve - the RBAC system checks if the rules of the current (inherited) subject dictate inheritance via the "i" mode or not. If they do, inheritance occurs again, if not, the subject of the process may be changed (if necessary). So, to sum it up, mode "i" causes only a single level inheritance, but this inheritance can be extended arbitrarily by further "i" flags.

6. Pontosan milyen jogok kellenek hard link létrehozosához?

Semmi más, mint "l" jog a linkelendő (forrás) fájlhoz, ami ezen felül nem lehet "h" (hidden) "Find" jog a linkelendő (forrás-) fájlhoz (ami azt jelenti, hogy nem lehet "hidden"), valamint "l" és "c" jog az elkészítendő hard linkhez. Ez utóbbi esetében még az sem gond, ha rejtett, mint ahogy nem gond az sem, ha sem a forrást, sem a célt tartalmazó könyvtárhoz nincs még "r" jogunk sem, sőt, az sem baj, ha "h" flag-gel el vannak rejtve előlünk. Amennyiben azonban a /proc/sys/kernel/grsecurity/linking_restrictions engedélyezve van, a forrásfájlnak a hard linkelési műveletet végrehajtó processz tulajdonában kell lennie, pontosabban a processz FSUID-jének kell megegyeznie a linkelendő file owner UID-jával. További korlátozás, hogy ha a a forrásfájlhoz képest bármilyen többletjogosutlsággal rendelkezünk a létrehozandó linkhez (kivéve persze a "c" jogot), akkor a Grsecurity megakadályozza a link létrehozását.

6. What permissions are exactly necessary for creating a hard link?

Nothing more than "l" permission to the source file to be linked, which also has not to be hidden (restricted with "h" "permission") Find permission to the source file to be linked (which means it must not be hidden), and additionally one needs "l" and "c" permissions to the destination file (the hard link to be created). The destination file can even be hidden. In additionally directories containing both source and destination files can be hidden and we don't even need the "r" permission to these directories. However, if /proc/sys/kernel/grsecurity/linking_restrictions is enabled, then the source file must be owned by the process attempting to make a hard link of it. To be more precise, the process' FSUID must equal the owner UID of the source file. Another restriction is that if we have any more permissions to the link to be created than to the source file (except the "c" permission of course), then Grsecurity will prevent creating the link.

7. Hogyan kezeli a Grsecurity RBAC rendszere a symlinkeket?

Futásidőben nem sok váratlan dolog van a symlink-kezelésben. A symlinkekre vonatkozó jogok természetesen nem érvényesek a célpontra, tehát ha egy symlink eléréséhez van jogunk, de a célpontjához nincs, akkor a célpontot nem fogjuk elérni. A dereference-hez egyébként a "find" jogon kívül nincs szükség másra, azaz elég, ha nem rejtett a symlink "find" jogra sincs szükség, tehát az sem baj, ha rejtett a symlink. Symlink létrehozásához "cw" jogra van szükség.
A policy szövegformátumról binárissá történő fordítása közben azonban - amit a gradm végez - van néhány trükk, amelyeknek célja az életciklusuk folyamán gyakran változó célpontú symlinkeket tartalmazó programcsomagok kezelésének megkönnyítése:
Amennyiben a policyben objectként felsorolva KÖZVETLEN HIVATKOZÁS található egy symlinkre, és ugyanebben a subjectben feljebb még nem szerepelt a KÖZVETLEN HIVATKOZÁS a link célpontjára, akkor ez a symlinkre mutató sor megkétszereződik: Az egyik sor nem meglepő módon magára a symlinkre vonatkozik, a másik viszont a symlink célpontjára állítja be ugyanazokat a jogosultságokat. (Ennek a duplikálásnak feltétele az is, hogy a symlinknek és célpontjának ugyanaz legyen a tulajdonosa.) FONTOS: Ez azt jelenti, hogy a symlink célpontja KÖZVETLENÜL is elérhetővé válik, nem csak a symlinken keresztül. Sőt, még azután is elérhető marad, ha esetleg letöröltük a symlinket. A policyben a symlink után következő sorokban már nem szabad felsorolni a célpontját is, mert a duplikálás miatt ez annak felel meg, mintha a célpontot kétszer írtuk volna be, ami hibának számít, és a gradm egész addig nem engedi betölteni a policyt, amíg ezt ki nem javítjuk.
Amennyiben a policyben link célpontja szerepet először, és csak utána a symlink maga, akkor nem történik meg a fent leírt duplikálás, hanem a symlinkre megadott jogok kizárólag a symlinkre fognak vonatkozni.
Ha nem objectként, hanem subjectként adunk meg symlinket, a gradm ott is behelyettesíti a célpontot a symlink helyett, de duplikálás nem történik. A futásidejű bináris policybe tehát a symlink helyett csakis annak célpontja kerül be subjectként (bár a logokban a symlink nevét látjuk). Ez azt jelenti, hogy a symlink célpontja a symlink törlése után is minden joggal rendelkezni fog, amit a symlink számára adtunk meg, viszont ha a letörölt symlink helyébe egy programfájlt rakunk, az nem fogja örökölni ezeket a jogokat.

7. How does Grsecurity RBAC handle symlinks?

There's not much to be surprised about Grsecurity's runtime symlink handling. Permissions applying to symlinks don't apply to their targets, of course. So, if we have the permission to access a symlink but not its target, we won't be allowed to access the target the same way as the symlink itself. To dereference a symlink we don't need any permission other than to "find" it, which means it's enough for the symlink just not to be hidden not even the "find" permission, which means a symlink can be dereferenced even when it's hidden. To create a symlink we need at least the "cw" permissions to it.
Contrary to this simplicity, we are facing some interesting quirks during the process of compiling the text format policy into binary by gradm. These quirks were added to make easier the handling of software packages containing symlinks with targets often changing with version changes:
If gradm finds an object in the policy which is actually a symlink AND it haven't yet seen its target somewhere earlier in this policy then this object line gets duplicated: Not surprisingly, one of the lines will apply to the symlink itself while the other line will set the same permissions for the target of the symlink. (A requirement for this duplication is that the owner of the symlink and its target be the same.) IMPORTANT: This means that the target also becomes directly accessible, not just via the symlink exclusively. Moreover, it remains accessible even after the deletion of the symlink. In the same subject it's not allowed to refer to the target of a symlink in a line below the line referring the symlink itself, since because of this duplication its equivalent to refer to the target twice, which is not allowed and gradm won't allow loading the policy until fixing this.
If the target precedes the symlink (in the same subject of course) then the duplication described above is simply omitted.
If gradm finds a symlink in the policy which is NOT an object but a SUBJECT then it makes a similar substitution but without duplicating the line. It means that in the binary runtime in-kernel policy we will only have the symlink's target as a subject but not the symlink itself (despite this, in the kernel logs grsecurity refers to this subject with the name (path) of the symlink, not with that of the actual target). This means that the target of the symlink - as a subject - will continue having all permissions originally "intended" to be given to the symlink, even after deleting that symlink. However, if we put an executable file in the place of the deleted symlink, it won't inherit anything of that permissions.

8. Hogy működik a beépített authentikáció?

A `gradm -P *` parancs /etc/grsec/pw fájlban tárolja el a speciális role-ok jelszavait. Sajnos, úgy tűnik, törölni nem lehet belőle. Ez a jelszóadatbázis a policy betöltésekor töltődik be a kernelbe, úgy, mint a RUID/RGID-role összerendelések, így `gradm -a *` parancs authentikációja nem userlandn-ben, hanem a kernelben történik! Ha megváltoztatjuk egy role jelszavát a /etc/grsec/pw fájlban, az a kernelben tárolt jelszóadatbázisra nincs azonnali hatással. A módosítások életbe lépéséhez újra kell tölteni a policyt, pl. a `gradm -r` paranccsal.

8. How does builtin authentication work?

Using the command `gradm -P *` one can store passwords for special roles in the file /etc/grsec/pw. Sadly I didn't find the way to remove entries from this file. This password database is loaded into the kernel together with the policy, just like RUID/RGID-role assignments. This means that the `gradm -a *` style authentication takes place entirely in the kernel, not in userland! Changing a password in the /etc/grsec/pw file doesn't affect the in-kernel authentication database, so to commit password changes actually, it's necessary to reload the policy (e.g. using the command `gradm -r`).

9. Hogy működik a PAM authentikáció?

A fent említett `gradm -a *` authentikációval szemben a `gradm -p *` (PAM) típusú authentikáció nem a kernelben tárolt jelszóadatbázist használja, hanem a PAM-et futásidőben. Ehhez a gradm egy nem dokumentált segédprogramot, a /sbin/gradm_pam parancsot hívja meg. A Grsecurity PAM service-ének neve "gradm", tehát egy /etc/pam.d/gradm nevű fájlt kell létrehozni, hogy ez működjön. A PAM authentikációval aktiválható role-ok "P" mode-ja legjobb tudomásom szerint azt jelenti, hogy minden role, aminek van joga átlépni ebbe a role-ba, kap egy implicit "/sbin/gradm_pam" subjectet elegendő joggal a PAM könyvtár szolgáltatásainak használatához. Ezek a jogok nem egy policy fájlban vannak definiálva, hanem a gradm forráskódjában, és mivel implicit módon jelen vannak az ezt igénylő role-ok ACL-jében, a /etc/grsec/policy fájlban további engedélyeket nem is lehet már adni ennek a subjectnek. Ez elég nagy problémat okozhat, ha a mi rendszerünkön éppen nem elegendőek a Grsecurity fejlesztők által megfelelőnek gondolt jogok, ilyenkor ugyanis a gradm forráskódjának módosítására kényszerülhetünk: http://forums.grsecurity.net/viewtopic.php?f=1&t=2831

9. How does PAM authentication work?

Contrary to the `gradm -a *` style authentication mentioned above, `gradm -p *` style (PAM based) actually uses PAM in runtime, instead of Grsecuty's in-kernel builtin database. To achieve this, gradm uses the undocumented helper program /sbin/gradm_pam. The PAM service name of Grsecurity is "gradm", so the file named "/etc/pam.d/gradm" has to be created. According to my experiences, the "P" mode of PAM authenticating roles causes every role - allowed to authenticate to that role - to have an implicit "/sbin/gradm_pam" subject having enough permissions to use the PAM library. Instead of some policy file, this subject is defined in the source code of gradm, and because it's implicitly present in the ACLs of the appropriate roles, there is no possibility of explicitly defining or extending the permissions of this subject. This can cause some headache if the permissions in an unmodified gradm given for "/sbin/gradm_pam" arent's sufficient on our system to use the PAM system. In this situation we may be forced to modify the source code of gradm: http://forums.grsecurity.net/viewtopic.php?f=1&t=2831