- Oscon blogja
- A hozzászóláshoz be kell jelentkezni
- 890 megtekintés
Hozzászólások
meglevo rendszer mennyire fajldalmas "atrakni" grsec-esre?
(apache, php, mysql, postfix, courier, par custom cucc a /home-bol)
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Attól függ milyen opciókat használsz. A grsec RBAC beállítása / ~alkalmazásszintű ACL / (gradm) még learning betanító móddal is igencsak kemény. De ha sikerül faszomántosra belőnöd, akkor egy újabb komoly védelmi sorompóval gazdagodik a rencer.
Viszont nagyon könnyen kicsukhatod magad a gépből, mert ugye ez kernelszintű védelem, tehát "root felett áll"...
/* persze ez nem KÖTELEZŐ opció, akarod használod (gradm -E), nem akarod nem használod */
A memóriavédelem (PaX) néhány eleme inkompatibilis bizonyos cuccokkal. Pl. restrict_mprotect() mellett nincs JRE, openoffice, Xorg (XFree86), libGL-t használó alkalmazások, kdeinit, iceweasel.
Az mplayer/mencoder pedig még a SEGMEXEC- típusú védelemmel nem megy, pageexec-el asszem már igen.
Azonban ezeket a védelmeket le lehet venni a problémás binárisokról (és a többi cuccon attól még megmarad), vagy a paxctl-el (ehhez patchelt binutilst kell használni PaXTeam honlapján fentvan), vagy chpax-al (ez deprecated módszer, de működik, és nem kell pecselni hozzá és pl. debian etchben megvan). Meg van még 1-2 grsec opció ami pár dologgal inkompatibilis, de ez bent van a kernel helpjében.
A SEGMEXEC, és a PAGEEXEC a syslogba naplóz ha kivág valami renitens jószágot a memóriából, a restrict_mprotect() viszont sehova.
A PaX memóriavédelem durva, nagyon leegyszerűsített fordításban 4szintű.
1. szinten semmi sincs. :) (disabled PaX)
2. szinten PAGEEXEC
3. szinten SEGMEXEC
4. szinten PAGEEXEC/SEGMEXEC+restrict_mprotect()
---------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Hát igen, az X elég sok engedményt követel magának.
Azt viszont figyelembe kell venni, hogy ez valamennyi memóriát meg prociidőt fog igényelni.
- A hozzászóláshoz be kell jelentkezni
SEGMEXEC pl. nem zabál sokat ahogy észrevettem, de PAGEEXEC se veszélyes sz'tem mai gépeknél már. Az inkompatibilitási listán viszont szerepel még a wine (ez se PAGEEXECel, se SEGMEXECel nem működik együtt), valamint a dosemu ami a grsec /proc restriction-al nem dolgozik együtt.
-------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Yó, persze igazad van. Sajnos nekem elég régicske gépem van (p3 1300MHz, >400MB SDRAM), szal nekem minden hertz számít. Most pl. elfogadhatóan megy a gép.
Amúgy a Beryl full incompat
- A hozzászóláshoz be kell jelentkezni
Nálam szépen elfutott anno AMD Duron 700-ason 128 majd később 256 MB SD rammal. :)
Igaz az még 2.4es kernel volt dögivel. :))
Beryl-el meg hasonló csicsákkal nem foglalkozom. Én mexoktam ezt a kétdimenziós asztalt itten már 1999 óta ugyanazzal a háttérrel. :-)
Bár ha Beryl OpenGL-es egy chpax -m után elvben mennie kéne. (?).
de nem gyengusz a géped picit az ilyen csicsákhoz ?
-----------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Annyira nem. Bár tény& való, fordításkor kikapcsolom. Főleg, ha valami KDE-szerűt forgatok
- A hozzászóláshoz be kell jelentkezni
akkor szvsz egy tuzfal mogotti desktop gepen folosleges szopas feltenni, de akkor egy serveren nem olyan nehez.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Elsődlegesen valóban serveren nagyon jó. pl. 0-day apache buffer overflow bug ellen.
De desktopon is elketyeg (0-day firefox bugnál pl.:).
Ezután a parancs után pl. (-m restrict_mprotect kikapcsolása az adott binárisokon).
Sőt a TPE-t csak ajánlani tudom desktopra. (segítségével az idegen binárisok futása megtiltható a megbízhatatlan felhasználók számára)
chpax -m /usr/bin/X11/Xorg /usr/lib/openoffice/program/soffice.bin /usr/bin/kdeinit /usr/lib/iceweasel/firefox-bin
stb.
---------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni