Grsecurity - Chroot jail restrictions/protect outside processes

Linux-haladó

Sziasztok

A címben említett grsec funkció kiváltásara valaki tud javasolni valami megoldást?

Előre is köszönöm.

  • 1317 megtekintés

( gyu v | 2018. 06. 06., sze – 15:32 )

Ha megírod, hogy ez a funkció pontosan mit is csinált, lehet könnyebben tud az olvasóközönség alternatívát is javasolni.
A névből még nem annyira tudom kikövetkeztetni, hogy ez pontosan mi, vagy mire jó.
Vagy legalábbis, ha csak simán próbálom JPÉ-parserrel értelmezni, akkor simán egy namespace is jó erre, pl. lxc/docker/akármi, ahol az abban futó processz nem tud "kiszólni", pl. signal-t küldeni külső process-nek, hiszen a saját namespace miatt nem is látja a többi processzt. Már ha jól értelmeztem, hogy mi a cél.

Ezt csinálja:

Protect outside processes

GRKERNSEC_CHROOT_FINDTASK
Related sysctl variables:

kernel.grsecurity.chroot_findtask

If you say Y here, processes inside a chroot will not be able to
kill, send signals with fcntl, ptrace, capget, getpgid, setpgid,
getsid, or view any process outside of the chroot. If the sysctl
option is enabled, a sysctl option with name "chroot_findtask" is
created.

A nagy részét (mindet?) egy apparmor profillal meg lehet oldani szvsz.

Ez a funkcio minden szempontbol "elrejti" a jail-ben futo folyamatok elol a tobbi futo folyamatot. Arra tudtam hasznalni, hogy pl tobb sql vagy web server verziot futtattam kulon jail-ben, nem zavartak egymast, kvázi "virtuális gépként"

Amig tudtam hasznalni a grsec-et nem volt gond, de mostmar mas megoldast kell talalnom.

Ha esetleg tudnal valamilyen linket kuldeni egy peldakkal telezsufolt oldalrol, azt megkoszonnem.

A namespace alapú izoláció jó lehet az üzemeltetési szempontok szerinti elkülönítésre, de biztonsági szempontból a grsecurity/PaX jóval többet ad ennél.

Egyrészt namespace esetén az adott "jailben" futó folyamatok és azok chroot használatai így már nem lesznek korlátozva (pl. egy chrootoló ftp daemon továbbra is látja majd a namespacen belüli többi folyamatot). Másrészt a grsec védelmi funkciói egymásra épülnek és kiegészítik egymást. Míg a grsec chroot hardening funkciói segítenek a privilégium szeparációt alkalmazó daemonok jobb korlátozását, addig a grsec TPE és a PaX mprotect resztrikciók lehetővé teszik, hogy egy támadó ne is tudjon egyszerűen új/saját kódot futtatni a jailben.

A szofisztikáltabb támadások ellen pedig a PaX kernel önvédelmi funkciói adnak hathatós védelmet. Egy hagyományos, valamelyik felkapott disztribúció által szállított kernelnél hiába lesznek elkülönítve namespace alapon a folyamatok. Egy komolyabb támadó a kernel hibáit kihasználva könnyedén módosítani tudja a user és namespace memóriában található struktúráit és azonnal teljes hozzáférést szerez a rendszer felett. A "hosztra" és minden namespacere rálátása lesz, mint neked rootként.

Szóval ha csak az üzemeltetés megkönnyítése miatt szeretnéd elkülöníteni a folyamatokat (pl. egy teszt rendszeren, ahol párhuzamosan sok hasonló környezetet kell futtatni és menedzselni), akkor a namespace alapú megoldások segíthetnek, de ha egy éles rendszeren, a biztonságot szem előtt tartva szeretnél korlátozásokat bevezetni és egy biztosabb alapot teremteni a szolgáltatások számára, akkor a grsec/PaX sok szempontból megkerülhetetlen.