Hozzászólások
Epp ma upgradeltem az etch debian rendszeremet. Az upgradenel uj libc6 glib meg mindenfele rendszer alapjait kepezo package frissult. A frissites soran kozolte hogy lehetnek gondok es o a serviceket most ujrainditgatja. Feltuno volt hogy a postfix es apachek 127! es kod dobasa utan nem indultak el a upgrade scriptnel, de gondoltam majd kezzel.... Na es ekkor jott a durva megdobbenes, hogy szinte midnen servicem, ami hasznalja a libcrypto.so.0.9.7 filet, erre hivatkozva nem indul el:
error while loading shared libraries: libcrypto.so.0.9.7: cannot enable executable stack as shared object requires: Permission denied
Persze megneztema symlnkeket es tokeletesen jok, jogosultsag is. Ezekutan probaltam googlebe nyomara akadni ennek a hibanak, es hat talaltam par bejegyzest, de konkretet megoldast nem olvastam sehol. Volt ahol teljesen felrebeszeltek, volt ahol aztmondtak kernel verzio fuggo a problema es probaljanak a hiba eszleloi ujabb kernelt frissiteni. Ezert most egy 2.6.11.12 es kernel fordul most grseces. Az info kedveert, eddig egy 2.4.31 grseces kernel volt. Szoval a lenyeg, tud e valaki a problemarol, es esetleg sikerult e kikuszobolni. Nagyon gaz a dolog, mert tenyleg mindent "szetkurt" wget ftp web mail.... uhh. Segisegeteket elorre is koszonom![/b]
- A hozzászóláshoz be kell jelentkezni
Ismert probléma.
Az új glibc figyelembe veszi, ha egy lib azt mondja magáról, hogy executable stack kell neki, és megpróbálja átállítani a verem memóriaterületére vonatkozó jogokat, amit viszont a PaX nem enged. Tehát vagy ki kell kapcsolni a PaX-ot (vagy globálisan vagy egyenként a chpax/paxctl segítségével minden egyes problémás program esetében), vagy meg kell patchelni a glibc-t, hogy úgy működjön, mint eddig, azaz magasról tegyen rá, hogy a lib szerint szükséges-e az executable stack (még nem találkoztam olyan libbel, amelynek tényleg szüksége lett volna erre).
Ha a glibc-t akarod patchelni, azt a következőképpen teheted meg:
Az elf/dl-load.c file-ban az 1315-ös sor környékén, az _dl_map_object_from_fd függvényben a
[code:1:0eee2920bb]if (__builtin_expect ((stack_flags &~ GL(dl_stack_flags)) & PF_X, 0))[/code:1:0eee2920bb]
elágazás a bűnös, ezt (és a hozzá tartozó kódot) kell eltávolítani. (Vagy beszúrsz egy "0 &&"-t a feltétel elé, az is tökéletes.)
- A hozzászóláshoz be kell jelentkezni
huh, akkor ertem mostmar a problemat. Azt nem gondoltam volna hogy a grsecel fog osszeakadni. Vagyi pontosabban a pax korlatozza. A glibc-be nem szivesen kontarkodnek bele :) Akkor inkabb a paxot kapcsolnam ki. Esetleg azt megtudnad mondani hogy hogy tegyem ezt? Vagy forgassak grsec nelkuli kernelt? Most lattam hogy a grsec forumatn aztmondjak ne upgradeljen senki, a probleman dolgoznak es nehany napon belul keszlesz....
A segitseged pedig nagyon koszonom!!!
- A hozzászóláshoz be kell jelentkezni
Nem kell a teljes grsecurity-t kikapcsolni, csak a PaX-ot (annak sem minden feature-ét, de most hirtelen meg nem mondom, melyik maradhat).
- A hozzászóláshoz be kell jelentkezni
ha lehallnak, akkor hallokeszulekre lesz szukseg!
t
- A hozzászóláshoz be kell jelentkezni