grsecurity 2.1.9

Titkosítás, biztonság, privát szféra

Hosszas várakozás után Brad Spengler ismét grsecurity patch-et adott ki a 2.4.32 / 2.4.33-rc2 / 2.6.17.7 kernelekhez. Az új verzió elérhető itt. Benne két új PaX funkció, és egyéb változások. A változások részletes listája itt.

( trey | 2006. 07. 31., h – 13:11 )

Kicsit kiegészítettem.

--
trey @ gépház

( wolphie | 2006. 07. 31., h – 15:12 )

We however continue to discourage the 2.6 series of kernels for production use for reasons that should by now be obvious to everyone.
Biztosan nincs igazuk, mert a hupon az emberek 56%-nak semmi baja vele :)

( Botond | 2006. 08. 01., k – 11:34 )

Provokatív kérdés egy egykori grsec felhasználótól: napjaink Xen-es kerneljei mellett kell még egyáltalán grsec?
Nem ismerem igazán a Xen-t, de úgy képzelem, hogy szolgáltatásokat (pl. httpd) ezentúl Xen alatt kell futtatni, abból úgysem tud kitörni a rosszindulatú felhasználó.
Javítsatok ki, ha butaságot kérdeztem!

Hírekre.
Nem az a Xen lényege, hogy user-space-ben futtatja a Linux-ot, így user-space-ben egy virtuális gépet hoz létre? Mert ha igen, akkor egy esetleges Apache hibát kihasználva kizárólag a virtuális gépet lehet elrontani. Mondjuk az is elég nagy baj, de talán kisebb, mintha a több más szolgáltatást futtató valós gépet is elrontanák.

Nagyjából és többé kevésbé ilyesmi. De mi van olyankor, ha:

- nekem egy gépen csak egy projektem fut, és ha azt egy darab Xen-be teszem, és azt vágják agyon, akkor beljebb vagyok?
- vagy mi van olyankor ha több domU-m van, de olyan hiba van a Xen-ben, ami a dom0-t érinti, akkor vajon nem lehet agyonvágni az egészet?

--
trey @ gépház

- nekem egy gépen csak egy projektem fut, és ha azt egy darab Xen-be teszem, és azt vágják agyon, akkor beljebb vagyok?
Nem. De ha az sshd a valós kernel alatt fut, akkor még távolról újra tudod indítani a Xen-t. Persze ha ezen a gépen egyáltalán semmi nincs az sshd-n kívül, akkor marad a grsec, vagy a SELinux.

- vagy mi van olyankor ha több domU-m van, de olyan hiba van a Xen-ben, ami a dom0-t érinti, akkor vajon nem lehet agyonvágni az egészet?
Valószínű grsec alól is ki lehet mászni. Gondolom legalább olyan valószínűtlen, mint java kóddal JVM alól kimászni, és root jogot szerezni. A Xen is csak arra jó, hogy plussz egy virtulizációs szintet bevezet, megnehezítve ezzel a károkozást.

Nem használtam még Xen-t, nem tudom, mennyire jó, csak érdekelnek a lehetőségek.
Grsec-et használtam, és az volt az érzésem, hogy a fönt említett 1 db sshd-t futtató gépnél bonyolultabb szervereken már kezelhetetlen. A policy fájl karbantartása nagyobb munkát okoz, mintha rendszeres időközönként újratelepíteném a rendszert. Ez persze nem a grsec hibája, egyszerűen így van. Valószínűleg SELinux policy-t sem kisebb munka összedobni, csak vannak Linux disztribúciók, amik ezt megcsinálják helyettem.

szerintem kicsit kevered a dolgokat. a xen-nek ill. a virtualizacionak ugy altalaban semmi koze nincs a biztonsaghoz. gondolj csak bele, amikor fizikai gepeket konszolidalsz virtualis gepekre, akkor igazabol nem tortenik mas, mint hogy a rezkabel helyet (mar ha halozatba voltak kotve egyaltalan a gepek) atveszi egy komplex hw/sw megoldas. ettol tuti nem lesz biztonsagosabb a virtualis gepekre epulo rendszer, de nem is ezert hasznaljak. ebbol az is kovetkezik, hogy a virtualis gepen pont annyi ertelme van biztonsagot erosito rendszereket hasznalni, mint igazi gepen.

> Valószínű grsec alól is ki lehet mászni.

ez igy van.

> Gondolom legalább olyan valószínűtlen, mint java kóddal JVM alól kimászni, és root jogot szerezni.

ez viszont nem igy van. a jvm a termeszetenel fogva kepes futasidoben kodot generalni, tehat barmilyen memoriakezelesi hibat shellcode futtatasara lehet hasznalni. egy jol konfiguralt grsec/PaX alatt viszont pont ezt a jogot lehet megtagadni (meg masokat is), ezert sokkal tobb munka kitorni belole (persze egy jvm grsec alatt pont ugyanolyan serulekeny, mint nelkule, de ez a jvm problemaja, nem a grsec-e). ha konkret jvm bugok erdekelnek, akkor keress ra a lengyel lsd-pl sracok par evvel ezelotti munkajara.