http://fellow.linuxforum.hu/kernel_felkonfig - "pax felülbírálása:"
bar opera mashogy all hozza, mint a mozilla (nem plug-in, hanem kozvetlen a java binarissal);
eloszor "-z" -vel szedd le az eddigi macerat, majd a "segmentation -" es "paging based non-executable pages" + "restrict mprotect()" kapcsold le;
+ jo lenne a 'cat /var/log/syslog | tail';
grsec: signal 11 sent to /usr/local/j2sdk1.4.2_03/jre/bin/java_vm[java_vm:10861] uid/euid:1000/1000 gid/egid:100/100, parent /usr/local/mozilla/mozilla-bin[mozilla-bin:8089] uid/euid:1000/1000 gid/egid:100/100
grsec: signal 11 sent to /usr/local/j2sdk1.4.2_03/jre/bin/java_vm[java_vm:10861] uid/euid:1000/1000 gid/egid:100/100, parent /usr/local/mozilla/mozilla-bin[mozilla-bin:8089] uid/euid:1000/1000 gid/egid:100/100
ami érdekes, hogy ezekk elenére nem száll el a Java-s cucctol, paxctl -elott meg elszált.
a pax-on belul a non-exec-pages kozul semmi sincs bekapcsolja, ezeket be kéne akkor még az Xfree-sem fog elinudlni, legalábbis a help szerint, vagy nem ?
tedd fel a .confiogod vhova, mert a sig11 loggolasa lehet a CONFIG_GRKERNSEC_SIGNAL bekapcsolasa miatt;
probald igy:
1. "-z" -vel leszeded az eddigi tenykedesed a /usr/local/j2sdk1.4.2_03/jre/bin/java_vm -rol, majd, majd inditod; ha nem megy:
2. mprotetc() kikapcsolasa erre a binarisra; ha meg mindig nem megy:
3. paging es segmen... kikapcsolasa;
+ jo lenne a "teljes" "(...)/syslog | tail"
"ami érdekes, hogy ezekk elenére nem száll el a Java-s cucctol, paxctl -elott meg elszált."
passz, en operaval hasznalom (szokoevente egyszer), es ott mashogy megy a java;
de a logika hasonlo;
"a pax-on belul a non-exec-pages kozul semmi sincs bekapcsolja, ezeket be kéne akkor még az Xfree-sem fog elinudlni, legalábbis a help szerint, vagy nem ?"
en jopar honapja hasznalom szinte maximumon (lasd kernel_felkonfig a) resze) es csak a "pax felulbiralasa" reszben leirtakkal talakoztam; mondjuk nem kdet hasznalok;
a "disable privileged io" tenyleg kiaksztja az Xet;
"mert a sig11 loggolasa lehet a CONFIG_GRKERNSEC_SIGNAL bekapcsolasa miatt;"
magayrul a grsec csak azt loggolja, hogy vmi sig11-el elszallt, nem a grsec okozza a problemat (_elvileg_);
"grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (java_vm:710) UID(1000) EUID(1000), parent (mozilla-bin:701) UID(1000) EUID(1 000)"
ezt ki lehet kerulni egy 'ulimit -c unlimited'-del, de altalaban nem segit, mert egy programhiba resze;
igen benne van a logolás, ami érdekes hogy aztmondja hogy sig 11 el kinyirta a java-t de megsem történt meg, lehet hogy a paxctl miatt mert levettem róla mindent
az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
Röviden az, hogy a progi (wolf3d) memóriakezelés szempontyából szarul van megírva.
A PAX a "memória" nemkívánatos területén észlelte, hogy a program "futtatni" akar. (execution attempt).
Ezért ezt a futtatási kérést kirúgta. (terminating task)...
A program azonban ezt meglehetősen rosszul viselte, és hirtelen extra erőforrásokat igényelt magának, amit a grsec nem nézett jó szemmel, (attempted resource overstep...) ezért kirúgta az egész progit úgy ahogy van.
[quote:c24a29ab1f="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
[quote:40566762cf="selli"][quote:40566762cf="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
ok
a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?
Leírás szerint 2.6-os ficsőr - én még 2.4ben élek -) -
[quote:b9afc84412="Oscon"][quote:b9afc84412="selli"][quote:b9afc84412="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
ok
a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?
Leírás szerint 2.6-os ficsőr - én még 2.4ben élek -) -
Leírás alapján én yes-re tenném.
leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?
[quote:a6203283cd="selli"][quote:a6203283cd="Oscon"][quote:a6203283cd="selli"][quote:a6203283cd="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
ok
a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?
Leírás szerint 2.6-os ficsőr - én még 2.4ben élek -) -
Leírás alapján én yes-re tenném.
leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?
leírás alapján 2.6-osban ez a vsyscall ficsőr hoz némi gyorsulást, de leírás szerint ez a ficsőr az exploit gyártók "fegyvere" lehet.
Szerintem komolyabban nem fogod megérezni,. a 2.4-es kernelben pl. ez a ficsőr totál nincs meg, és nem panaszkodom a sebességre.
"a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?"
Y, hacsak nem debian sid alatt vagy, de ez benne van a kernel_felkonfigban;
hagyne irjam le nszer ugyanazt;
"Openoffice,gmplayer nekem muxik alapbol is, vagy igy stabilabbak ? "
ha siman mennek, akkor nem allitottad eleg erosre a paxot;
"winex-el kuzdok"
azzal lehet, mert gany az egesz; inkabb a winet eroltesd;
"mplayer: /usr/lib/libGL.so.1: no version information available (required by mplayer)"
letezik az /usr/lib/libGL.so.1?
egyebekent forgasd ujra az mplayert forrasbol;
"leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?"
elemeletileg minden lassit vmennyit, gyakorlatilag en meg nem vettem eszre;
Ha jól értem akkor a proftpd a libc-ben probált végrahajtani kódot. Ez most azt jelenti, hogy valaki megprobálta feltörni a gépet 192.168.1.2-ről( ami a szomszéd gép, és szerintem csak annyi volt, hogy windos-commander/ftp/ majd egyszercsak kifagy a wcommander könytárváltás után)
----[ chpax 0.6 : Current flags for /usr/sbin/proftpd (PeMRxS) ]----
* Paging based PAGE_EXEC : enabled (overridden)
* Trampolines : not emulated
* mprotect() : restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : enabled
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer (pemRxs) ]----
* Paging based PAGE_EXEC : disabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
ez is csak a binaris win32 codecek miatt kell;
es ugyanezeke a beallitasok vannak a doksimban;
"van valakinek infoja arrol hogy egy ilyen majdnem full grsec mennyivel lassul ( 1,2 % elmegy sztmem)"
imho a kerdesben van a hiba, mert win alatt sem azt kerdezed, hogy mennyit lassit egy viruskergeto, hanem, hogy mennyire hatasos;
en nem vettem eszre lassulast, bar nem a kdet es hasonlo csirivili dolgokat reszesitem elonyben;
a winex kozelebe sem er a winenak, raadasul mivel mindeki p2p szerzi be a binaris valtozatot, ezert iedalis egy rootkitnek;
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer
* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer (PemRxs) ]----
* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
$ mplayer vmi_ami_w32_kodeket_igenyel.wmv
Leállítva
$ cat /var/log/syslog | tail
May 10 20:43:13 localhost kernel: PAX: execution attempt in: <anonymous mapping>, 0857a000-08851000 00000000
May 10 20:43:13 localhost kernel: PAX: terminating task: /usr/local/bin/mplayer(mplayer):11863, uid/euid: 1000/1000, PC: 085a5a90, SP: bb733d74
May 10 20:43:13 localhost kernel: PAX: bytes at PC: 55 89 e5 52 b8 05 00 00 00 ba 2c 75 07 08 c1 e0 05 05 60 04
May 10 20:43:13 localhost kernel: PAX: bytes at SP: 00423386 cfcf9898 bb733e9c 00000000 087486e8 087490c8 087490c8 00000000 087486e8 bb733e9c 00417f3a 00000000 087486a8 08744528 33564d57 4691be9c 00914d00 468b993a 4691be9c 00000000
May 10 20:43:13 localhost kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /usr/local/bin/mplayer[mplayer:11863] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:15190] uid/euid:1000/1000 gid/egid:1000/1000
Oscon:
"Én a következőt javaslom a kernel_felkonvhoz:
(...)"
_hatalmas_ thx, at fogom nezni es beleirom + ugyis tervezek egy "akik nelkul ..." szekciot;
ma lesz egy kisebb frissites, de meg ezek nelkul;
selli:
"mprotect után sokkal jobb es meg az opengl is megy, pedig azt olvastam hogy nem fog. hmm ?????????????????????????"
ezt targyaljuk le;
tudtommal (es tapasztalatom szerint) csak a binaris nvidia meghajtohoz adott libGL.so-val problemazik;
nalad milyen libGL.so van fenn?
"chpax -Mps vagy mPS az erosebb."
'chpax -h' - a nagybetu bekapcsolja a pax ellenorzeset, a kicsi kikapcsolja adott dunkciora; hacsak nem "soft mod"ban futtatod a paxot (alapbol kikpacsolva minen ellenorzese, de bekapcsolhato), akkor csak arra kell koncentralni, hogy _kikapcsolja_ egy-ket ellenorzest bizonyos binarisokra;
"( chpax -sp wolf.x86 megoldja)"
errol van szo, nehany binarisnal felul kell biralni a paxot;
egyebkent udvozlunk az extra paranoiasok vilagaban; ugye van egy tukor a monitor vmelyik sarkaban? ;-)
Hogyan lehetne a pax-ot ideiglenesen likvidalni ?
leirom mirol lenne szo:
Van egy progi install ami onkicsomagolos es egy java_vm-et telepíit a /tmp/... -be es az probalja használni a további lepesekben. de ez koztudott hogy nem megy pax-val. Hogyan lehetne megcsinálni hogy az ujonnal létrejött(gondolom kicsomagolja a tmp-be) fajlok chpax -mps jojjenek letre.
[quote:dfef2b9111="fellow"]Oscon:
"Én a következőt javaslom a kernel_felkonvhoz:
(...)"
_hatalmas_ thx, at fogom nezni es beleirom + ugyis tervezek egy "akik nelkul ..." szekciot;
ma lesz egy kisebb frissites, de meg ezek nelkul;
selli:
"mprotect után sokkal jobb es meg az opengl is megy, pedig azt olvastam hogy nem fog. hmm ?????????????????????????"
ezt targyaljuk le;
tudtommal (es tapasztalatom szerint) csak a binaris nvidia meghajtohoz adott libGL.so-val problemazik;
nalad milyen libGL.so van fenn?
"chpax -Mps vagy mPS az erosebb."
'chpax -h' - a nagybetu bekapcsolja a pax ellenorzeset, a kicsi kikapcsolja adott dunkciora; hacsak nem "soft mod"ban futtatod a paxot (alapbol kikpacsolva minen ellenorzese, de bekapcsolhato), akkor csak arra kell koncentralni, hogy _kikapcsolja_ egy-ket ellenorzest bizonyos binarisokra;
"( chpax -sp wolf.x86 megoldja)"
errol van szo, nehany binarisnal felul kell biralni a paxot;
egyebkent udvozlunk az extra paranoiasok vilagaban; ugye van egy tukor a monitor vmelyik sarkaban? ;-)
igaz régi, de ez legalább nem fagy X-konzol-X vátáskor
- dehogy van soft mod :) annál parásabb vagyok.
"chpax -Mps vagy mPS az erosebb." tudom mit jelent (sejtem) , csak az nem tudom melyiket vegyem le(mintha nem lenne teljesen mindegy)
-tükör nincs de jó ötlet. :)
grsec kijöhetne már a 2.6.6-hoz... milyen gyakran frissitik?
az Addres Space Layout Randomizacin-ot ke kellet kapcsolni, mert igy a hibas programok konyebben elszalnak, es hat ugy a java-ban azert lehet bug boven.
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer (PemRxs) ]----
* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
$ mplayer vmi_ami_w32_kodeket_igenyel.wmv
Leállítva
$ cat /var/log/syslog | tail
May 10 20:43:13 localhost kernel: PAX: execution attempt in: <anonymous mapping>, 0857a000-08851000 00000000
May 10 20:43:13 localhost kernel: PAX: terminating task: /usr/local/bin/mplayer(mplayer):11863, uid/euid: 1000/1000, PC: 085a5a90, SP: bb733d74
May 10 20:43:13 localhost kernel: PAX: bytes at PC: 55 89 e5 52 b8 05 00 00 00 ba 2c 75 07 08 c1 e0 05 05 60 04
May 10 20:43:13 localhost kernel: PAX: bytes at SP: 00423386 cfcf9898 bb733e9c 00000000 087486e8 087490c8 087490c8 00000000 087486e8 bb733e9c 00417f3a 00000000 087486a8 08744528 33564d57 4691be9c 00914d00 468b993a 4691be9c 00000000
May 10 20:43:13 localhost kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /usr/local/bin/mplayer[mplayer:11863] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:15190] uid/euid:1000/1000 gid/egid:1000/1000
nekem engedi lejáccani a (g)mplayerből valami.wmv-t...
de mplayerből is lejácca. igaz nekem régebbi mplayerem van, lehet hogy azért.
grsec acl nem ereszti ki netre, úgyhogy így védem ki a remote dó'gait...-)
-----------
paxtest 0.9.6 nálam ezt fussa:
Linux osconsfortress 2.4.18-gekaichromage #1 2004. máj. 9., vasárnap, 15.00.04 CEST i686 unknown
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : No randomisation
Heap randomisation test (ET_DYN) : 17 bits (guessed)
Main executable randomisation (ET_EXEC) : 16 bits (guessed)
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Killed
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed
1. Deny writing to /dev/kmem, /dev/mem, and /dev/port = Y
Ez úgy tapasztaltam, hogy dosemuval sem kompatibilis.
Proc restrictions = Y
Itt is tapasztaltam inkompatibilitási problémákat. énszerintem jobba
PROC_USERGROUP yes, +PROC_GID (pl. 1010).
Így ha valakinél gond van, akkor őt csak be kell sorolni a példában szereplő 1010-es csoportba, a többiek maradnak letiltva.
A Thrusted Path executiont is mindenképpen be kellene kapcsolni, én szerintem itt úgy, hogy
TPE _ALL yes, TPE_GID (pl. 1013)...Aki a 1013-asban van, az futtatás szempontjából untrusted. Ez a következőkre jó.
Ugye ha a /home, és a /tmp könyvtárakat noexec-el csatolod be, akkor onnan nem lehet semmit futtatni, kivéve, hogyha
a /lib/ld-linux.so.2 /home/../binaris -al próbálod indítani. Ha a user benne van az untrusted csoportban (=megbízhatatlan), akkor
a bináris segmentation fault-al elszáll, és egy aranyos grsec log jelenik meg, hogy mikor melyik user akaródzott untrusted cuccost futtatni. szerintem baromi hasznos a TPE kár kikapcsolni.
Sőt, szerintem a socket restrictiont is be kéne kapcsolni.
A socket all gid (csoport) az, aki se nem kezdeményezhet hálózati kapcsolatot (socket), se nem indíthat hálózati szervízt (bind) Ebbe a GIDszámú csoportba soroljuk be a rootot. (=rendszergazda ne internetezgessen, és ne indítson server típusú cuccot)
A socket_server gidbe meg soroljuk be a usereket. userek ne indítgassanak servereket.
A socket_kliens gidbe azokat a "usereket" kell besorolni, akik nevében server daemonokat futnak.
Ők nekik nem biztos, hogy muszáj netezgetni. -)
[quote:05039359aa="Oscon"]Én a következőt javaslom a kernel_felkonvhoz:
1. Deny writing to /dev/kmem, /dev/mem, and /dev/port = Y
Ez úgy tapasztaltam, hogy dosemuval sem kompatibilis.
Proc restrictions = Y
Itt is tapasztaltam inkompatibilitási problémákat. énszerintem jobba
PROC_USERGROUP yes, +PROC_GID (pl. 1010).
Így ha valakinél gond van, akkor őt csak be kell sorolni a példában szereplő 1010-es csoportba, a többiek maradnak letiltva.
A Thrusted Path executiont is mindenképpen be kellene kapcsolni, én szerintem itt úgy, hogy
TPE _ALL yes, TPE_GID (pl. 1013)...Aki a 1013-asban van, az futtatás szempontjából untrusted. Ez a következőkre jó.
Ugye ha a /home, és a /tmp könyvtárakat noexec-el csatolod be, akkor onnan nem lehet semmit futtatni, kivéve, hogyha
a /lib/ld-config /home/../binaris -al próbálod indítani. Ha a user benne van az untrusted csoportban (=megbízhatatlan), akkor
a bináris segmentation fault-al elszáll, és egy aranyos grsec log jelenik meg, hogy mikor melyik user akaródzott untrusted cuccost futtatni. szerintem baromi hasznos a TPE kár kikapcsolni.
Sőt, szerintem a socket restrictiont is be kéne kapcsolni.
A socket all gid (csoport) az, aki se nem kezdeményezhet hálózati kapcsolatot (socket), se nem indíthat hálózati szervízt (bind) Ebbe a GIDszámú csoportba soroljuk be a rootot. (=rendszergazda ne internetezgessen, és ne indítson server típusú cuccot)
A socket_server gidbe meg soroljuk be a usereket. userek ne indítgassanak servereket.
A socket
Tisztázuk:
ezt most server-re, vagy desktop gépre is ajánlod?
ha desktopra is akkor ez már parás :)
Tisztázuk:
ezt most server-re, vagy desktop gépre is ajánlod?
ha desktopra is akkor ez már parás :)
a kettő nem mindig külön választható.
A linuxos desktopok egy jó része a mögötte levő winek számára átjáró, és local mail server, és samba is lehet egyben.
Sz'al ez nem mindig kettéválasztható. sok desktopot használnak egyben serverként vagy fordítva.-)
most tekintsünk el az itthoni gépemtőla, ami elég macerás.
Itt több lokális user is van.
magyar KDE-vel, mozillaval (elöttük junkbuster), mplayer-el, OOoval, hogy mindenki örüljön. engem kivéve ált. kattingatós userek.
A leveleket exim+fetchmail+procmail szortírozza közöttü(n)k, mivel adslhez jár több mail alias is ugyebár.
Ill. fut még egy egyelőre localhost listenen egy apache+php+mysqles daemonom is mer' azt meg tanulgatom, ill. tanulgatnám, csak hát valami mindég közbejön. ha majd eljutok benne addiig, hogy tudom már mire használni , akkor majd kinyitom kifelé is...
Ráadásul meg kiemelten paranoid vagyok, ha internetről van szó. ez talán baj? -)
[quote:3c6b6934c3="selli"]Hogyan lehetne a pax-ot ideiglenesen likvidalni ?
leirom mirol lenne szo:
Van egy progi install ami onkicsomagolos es egy java_vm-et telepíit a /tmp/... -be es az probalja használni a további lepesekben. de ez koztudott hogy nem megy pax-val. Hogyan lehetne megcsinálni hogy az ujonnal létrejött(gondolom kicsomagolja a tmp-be) fajlok chpax -mps jojjenek letre.
[quote:58902b2e86="PaXTeam"][quote:58902b2e86="selli"]Hogyan lehetne a pax-ot ideiglenesen likvidalni ?
leirom mirol lenne szo:
Van egy progi install ami onkicsomagolos es egy java_vm-et telepíit a /tmp/... -be es az probalja használni a további lepesekben. de ez koztudott hogy nem megy pax-val. Hogyan lehetne megcsinálni hogy az ujonnal létrejött(gondolom kicsomagolja a tmp-be) fajlok chpax -mps jojjenek letre.
[quote:9b4aeb18c9="fellow"]Oscon:
selli:
"mprotect után sokkal jobb es meg az opengl is megy, pedig azt olvastam hogy nem fog. hmm ?????????????????????????"
ezt targyaljuk le;
tudtommal (es tapasztalatom szerint) csak a binaris nvidia meghajtohoz adott libGL.so-val problemazik;
nalad milyen libGL.so van fenn?
Eddig 4496-os nvdriver volt, az meg elviselte az mprotect-et.
Most mar 5336-van az nem szereti.
[quote:c148158e30="selli"]
CONFIG_PAX_NOELFRELOCS
CONFIG_GRKERNSEC_IO
kell nekem ?
1.9.9h-ban a noelfrelocs dangerousnak van jelölve.
Most olvasgatom az újban, és bár angolban nem vagyok egy nagy eresztés, de szerintem ne kapcsold be.
sz'tem még mindig könnyen lehet, hogy ha bekapcsolod, akkor mondjuk paxtest határára egyszercsak futás közben a linux kernel elszáll, és semmilyen parancsra a továbbiakban nem reagál, ill. init 0/6-ra ugyanez.
grkernsec_io új ficsőrnek tűnik, leírás szerint xserver nincs, ha bekapcsolod.
ha nem kell xserver, akkor sz'tem nyugodtan benyomhatod, de ha kell, akkor inkább ne.
"Openoffice,gmplayer nekem muxik alapbol is, vagy igy stabilabbak ? "
ha siman mennek, akkor nem allitottad eleg erosre a paxot;
>>majdnem fullos a config
"winex-el kuzdok"
azzal lehet, mert gany az egesz; inkabb a winet eroltesd;
>> nem megy 3d-s cuccok, egyébként már müxik
"mplayer: /usr/lib/libGL.so.1: no version information available (required by mplayer)"
letezik az /usr/lib/libGL.so.1?
egyebekent forgasd ujra az mplayert forrasbol;
>> grsec elott meg jo volt, (forrasbol telepítve)
"leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?"
>>elemeletileg minden lassit vmennyit, gyakorlatilag en meg nem vettem eszre;
nem is lassit sokat:
kernel comp. with make -j 3
without grsec
real 6m51.699s
user 6m26.915s
sys 0m24.574s
with grsec
real 6m59.487s
user 6m28.988s
sys 0m28.020s
startx
without grsec
27.67 sec
with grsec
28.34
ennyi szerintem nem szamit a pluss 10x biztonaghoz kepest. ;)
Oscon:
hatize, eddig azt hittem, hogy paranoias vagyok, de ne erts felre, de ez a socket restriction pillanatnyilag sok(k); majd kicsit kesobb ...
xdm: epp most rugtam ki egy csomo csomagot (deborphan + kezi valogatas), inkabb ezt is kesobb cserelnem le;
magyaritas?
en is gondolkodtam ezen, de per pillanat a kernel_felkonfigot kene "befejezni", majd a faqt, majd ... nos a 3. meg nem publikus; de koze lesz a debianhoz ;-)
"nincs frame buffer, ez egy nvidia bug utanaolvastam majd javítjak (hahaha ) ezert tertem vissza egy regire"
miota jo kis tnt2 vantarol fx5600ra valtottam nalam is rendetlekedik, pld _neha_ fagy 1024 felett, 16bit felett, stb stb; jo sok piszkalas utan kiderult, hogy a via apollo pro chipsetet nem epp ilyen modernebb kartyakhoz terveztek;
persze van megoldas: nv; ez is tud xv-t es ugyse jatszom sokat; enigma, lbreakout2, stb;
"wolkot nem használom, kéne?"
ha van kedved miert ne, van errol szo a kernel_felkonfigban;
"Akkor most mivan?"
problad meg -spm es reprudokalni a hibat;
ha nem eleg, nez szett a grsec forumon;
[quote:875f92e593="fellow"]"nincs frame buffer, ez egy nvidia bug utanaolvastam majd javítjak (hahaha ) ezert tertem vissza egy regire"
miota jo kis tnt2 vantarol fx5600ra valtottam nalam is rendetlekedik, pld _neha_ fagy 1024 felett, 16bit felett, stb stb; jo sok piszkalas utan kiderult, hogy a via apollo pro chipsetet nem epp ilyen modernebb kartyakhoz terveztek;
persze van megoldas: nv; ez is tud xv-t es ugyse jatszom sokat; enigma, lbreakout2, stb;
"wolkot nem használom, kéne?"
ha van kedved miert ne, van errol szo a kernel_felkonfigban;
"Akkor most mivan?"
problad meg -spm es reprudokalni a hibat;
ha nem eleg, nez szett a grsec forumon;
nem hinném hogy chipset probléma: i845-ös chipset + gef2 ( nincs generációbeli különbség sem)
a logban ez van:
Badness in pci_find_subsys at drivers/pci/search.c:167
kernel: Call Trace: [<c02b46f6>] [<c02b472d>] [<c02b4540>] [<e0c82ee1>] [<e0b582af>
kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
kernel: Call Trace: [<c02b46f6>] [<c02b472d>] [<c02b4540>] [<e0c82ee1>] [<e0b582af>
kernel: Linux version 2.6.5-grsec (root@sunset) (gcc version 3.2.3) #17 Tue May 11 17:0
nem fagy csontra mert van log + ssh kill X müxik
"problad meg -spm es reprudokalni a hibat;"
szerintem egyszerű bug a proftp-ben
"igaz régi, de ez legalább nem fagy X-konzol-X vátáskor"
99% framebuffer a bunos, kapcsold le;
http://fellow.linuxforum.hu/faq/faq-all.html#q1_4_11
"tudom mit jelent (sejtem) , csak az nem tudom melyiket vegyem le(mintha nem lenne teljesen mindegy)"
'chpax -v'
-M restrict mprotect()
-m do not restrict mprotect()
-P enforce paging based non-executable pages
-p do not enforce paging based non-executable pages
-S enforce segmentation based non-executable pages
-s do not enforce segmentation based non-executable pages
tehat az -mps _kikapcsolja_ ezt a 3 ellenorzest, az -MPS _visszakapcsolja_; mivel egy binaris alapallapotban PeMRxS beallitasokkal bir, ezer alapallapothoz kepest nem tudod erosebbre allitani;
"grsec kijöhetne már a 2.6.6-hoz... milyen gyakran frissitik?"
1-2 het;
enegem most jobban erdekel, hogy mi van a wolkkal...
oke, meg nincs uj release, de a fejlesztes is leallt?! ( http://sourceforge.net/mailarchive/forum.php?forum_id=8245 )
[quote:49da667ede="fellow"]"igaz régi, de ez legalább nem fagy X-konzol-X vátáskor"
99% framebuffer a bunos, kapcsold le;
http://fellow.linuxforum.hu/faq/faq-all.html#q1_4_11
"tudom mit jelent (sejtem) , csak az nem tudom melyiket vegyem le(mintha nem lenne teljesen mindegy)"
'chpax -v'
-M restrict mprotect()
-m do not restrict mprotect()
-P enforce paging based non-executable pages
-p do not enforce paging based non-executable pages
-S enforce segmentation based non-executable pages
-s do not enforce segmentation based non-executable pages
tehat az -mps _kikapcsolja_ ezt a 3 ellenorzest, az -MPS _visszakapcsolja_; mivel egy binaris alapallapotban PeMRxS beallitasokkal bir, ezer alapallapothoz kepest nem tudod erosebbre allitani;
"grsec kijöhetne már a 2.6.6-hoz... milyen gyakran frissitik?"
1-2 het;
enegem most jobban erdekel, hogy mi van a wolkkal...
oke, meg nincs uj release, de a fejlesztes is leallt?! ( http://sourceforge.net/mailarchive/forum.php?forum_id=8245 )
nincs frame buffer, ez egy nvidia bug utanaolvastam majd javítjak (hahaha ) ezert tertem vissza egy regire
megint foglalkoztam egy kicsit a grsecurityvel:
egyreszt oscon kollega tippjeit (maj 10) lassan feldolgozom;
eddig egyetlen problema a tpe miatt az /usr/local/bin jogosultsagat kelett alltani (a-w, u+w);
masreszt picit teszteletem (debian sid):
1. CONFIG_PAX_NOVSYSCALL - meg mindig fagy boot elejen;
2. CONFIG_GRKERNSEC_KMEM - X, ha ujrainditom (ctrl+alt+backspace), akkor _neha_ sig11;
May 20 16:04:13 localhost kernel: grsec: attempted mmap write of /dev/[k]mem by /usr/X11R6/bin/XFree86[XFree86:20005] uid/euid:0/0 gid/egid:0/0, parent /usr/X11R6/bin
/xdm[xdm:19822] uid/euid:0/0 gid/egid:0/0
3. CONFIG_PAX_NOELFRELOCS - minden oke lenne, de az o/a pluginjei nem mennek , libnpp.so -val van problema; es a binaris nvidia drivert hasznalva az X is sig11, akkor mikor a libGL.so akar az nvidia.o -val kommunkialni meg a X felallasa soran (sorry, log most nem talalok, de XFree86.0.log itt akad el a GLX extension betoltesenel);
harmadreszt a javanak problema: az mprotect, a non-executable pages, a trusted path, stb en inkabb éeszdtem, ugyse szoktam semmire se hasznalni;
ezeket majd beleirom a kernel_felkonfigba, lesz egy kulon grsec resz mar;
oscon:
hat, a socket restriction lehet, hogy nem desktop gepekre talatak ki;
all -ba nem rakhatom a rootot, mert nalam o futtatja a daemonokat, es ...
klient-be sem rakhatom, mert akkor nem megy az apt;
May 21 07:45:40 localhost kernel: grsec: attempted connect by /usr/lib/apt/methods/http[http:4258] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/apt-get[apt-get:32479] u
id/euid:0/0 gid/egid:0/0
az usert nem rakhatom serverbe, mert az xfce4 nem indul;
May 21 07:39:56 localhost kernel: grsec: attempted bind() by /usr/bin/xfce4-session[xfce4-session:5706] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:163
44] uid/euid:1000/1000 gid/egid:1000/1000
mivel desktop gep, csak ez a ket tenylegesen hasznalt account van;
vszinuleg at lehet majd hidalni a problemakat, majd egy kicsit kesobb;
Oscon:
"Ezzel vitába szállnék
chpax -X binaris --al még "erõsebbre" is lehet állítani."
oke, akkor felreertek vmit, mert a CONFIG_PAX_RANDEXEC helpjeben ez all:
"By saying Y here the kernel will randomize the base address of normal ET_EXEC ELF executables as well."
nalam ez ugy jott le, hogy ezentul _alapbol_ minden elf binarison rajta lesz a "randomize ET_EXEC base";
de az alapbeallitas valoban PeMR_x_S;
no, nalam itt ellentmondas van;
Röviden az, hogy a progi (wolf3d) memóriakezelés szempontyából szarul van megírva.
A PAX a "memória" nemkívánatos területén észlelte, hogy a program "futtatni" akar. (execution attempt).
Ezért ezt a futtatási kérést kirúgta. (terminating task)...
A program azonban ezt meglehetősen rosszul viselte, és hirtelen extra erőforrásokat igényelt magának, amit a grsec nem nézett jó szemmel, (attempted resource overstep...) ezért kirúgta az egész progit úgy ahogy van.
hat, a socket restriction lehet, hogy nem desktop gepekre talatak ki;
all -ba nem rakhatom a rootot, mert nalam o futtatja a daemonokat, es ...
klient-be sem rakhatom, mert akkor nem megy az apt;
Na itt jón egy nagy trükk:
INIT alatt létrejönnek a kapcsolatok. pl. adsl connect, stb...
de ha belépsz, és poff-al lekapcsolódsz, akkor már nem mehetsz vissza login után.
Az INIT alatt létrejönnek az iptables szabályok, de login után már nem férsz hozzá ahhoz sem.
(=tehát senki sem fogja a jól beállított iptables szabályokat félrebuzerálni)
Sz'al sz'tem nyugodtan mehetnek ALL-ba.
May 21 07:45:40 localhost kernel: grsec: attempted connect by /usr/lib/apt/methods/http[http:4258] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/apt-get[apt-get:32479] u
id/euid:0/0 gid/egid:0/0
Én a köv.-t csináltam meg. Módosított a /var/lib/dpkg /var/cache/apt..stb.
jogosultságokat, így userként futtatom az apt-get update; apt-get -d upgrade parancsokat.
Ill. a "cron-user" futtatja őket a user nevében, mer' lusta disznó vagyok.
Majd a "root-cron" futtatja durván 40 percre rá a mount -o remount,exec /tmp;
apt-get -y upgrade; mount -o remount,noexec /tmp; szkriptet.
Így a rendszergazdának nem kell neteznie egyáltalán.
az usert nem rakhatom serverbe, mert az xfce4 nem indul;
May 21 07:39:56 localhost kernel: grsec: attempted bind() by /usr/bin/xfce4-session[xfce4-session:5706] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:163
44] uid/euid:1000/1000 gid/egid:1000/1000
Nálam több account van, ezért kdm-et használok bejelentkezéskezelőnek.
(és a többi account miatt kde 2.2.2-t magyarítással). A pingvin is megmarad és
a kde is jóllakik.) néhány darab Attempted bind kdeinit ugyan megjelenik, de ettől még minden működik.
Esetleg próbálhatod az xdm+xfce-t, vagy?
-------------------
Arra gondoltam, esetleg a grsec funkcióit jó lenne teljesen "magyarítani" a Configure.help alapján.
Van pár dolog ami magától értetődő. socket restrictions, logging stb.
de pl. a Link, FIFO restrictions, PAX-t jó lenne magyarra ferdíteni...
nemreg kerult be sid ala egy uj libc6 verzio, ami tamogatja a sysvcall tiltasat;
glibc (2.3.2.ds1-14) unstable; urgency=low
(...)
- debian/patches/glibc232-remove-vsyscall.dpatch: Remove __ASSUME_VSYSCALL
to fix the system startup failure on the machine using PAX.
(Closes: #245563)
Hozzászólások
[quote:d823696485="Anonymous"]Fagyott a java_vm grsec alatt
kiadtam a
paxctl -pemrxs java_vm parancsot, most nem fagy ki
gondoltam kiprobalom:
paxctl -PEMRXS java_vm es meg mindeg nem fagy ???????????
ez normális ? a 2. parancs nem az elso inverze ? vagy most mivan ?
paxctl 0.2
2.6.5-grsec
chpax 0.6 tapasztalatok: (grsec 1.9.9h + 2.4.18):
chpax -mprsx /usr/X11R6/bin/XFree86
chpax -Mprs /usr/java/j2re1.4.*/bin/*
chpax -MpRs /opt/OpenOffice.org*/program/soffice.bin
chpax -MpRs /usr/bin/wine.bin
chpax -mPRs /usr/bin/gmplayer
http://fellow.linuxforum.hu/kernel_felkonfig - "pax felülbírálása:"
bar opera mashogy all hozza, mint a mozilla (nem plug-in, hanem kozvetlen a java binarissal);
eloszor "-z" -vel szedd le az eddigi macerat, majd a "segmentation -" es "paging based non-executable pages" + "restrict mprotect()" kapcsold le;
+ jo lenne a 'cat /var/log/syslog | tail';
fellow
"nagyon jo ez a forum, jo elvagyok magammal, de fo hogy talaltunk megoldast"
engem erdekel a tema, irj batran;
"grsec 1.9.9h + 2.4.1"
hat ez nem ma volt...
a nagybetu engedejez, erre alapesetben nincs szukseged;
fellow
logbol részlet:
grsec: signal 11 sent to /usr/local/j2sdk1.4.2_03/jre/bin/java_vm[java_vm:10861] uid/euid:1000/1000 gid/egid:100/100, parent /usr/local/mozilla/mozilla-bin[mozilla-bin:8089] uid/euid:1000/1000 gid/egid:100/100
grsec: signal 11 sent to /usr/local/j2sdk1.4.2_03/jre/bin/java_vm[java_vm:10861] uid/euid:1000/1000 gid/egid:100/100, parent /usr/local/mozilla/mozilla-bin[mozilla-bin:8089] uid/euid:1000/1000 gid/egid:100/100
ami érdekes, hogy ezekk elenére nem száll el a Java-s cucctol, paxctl -elott meg elszált.
a pax-on belul a non-exec-pages kozul semmi sincs bekapcsolja, ezeket be kéne akkor még az Xfree-sem fog elinudlni, legalábbis a help szerint, vagy nem ?
tedd fel a .confiogod vhova, mert a sig11 loggolasa lehet a CONFIG_GRKERNSEC_SIGNAL bekapcsolasa miatt;
probald igy:
1. "-z" -vel leszeded az eddigi tenykedesed a /usr/local/j2sdk1.4.2_03/jre/bin/java_vm -rol, majd, majd inditod; ha nem megy:
2. mprotetc() kikapcsolasa erre a binarisra; ha meg mindig nem megy:
3. paging es segmen... kikapcsolasa;
+ jo lenne a "teljes" "(...)/syslog | tail"
"ami érdekes, hogy ezekk elenére nem száll el a Java-s cucctol, paxctl -elott meg elszált."
passz, en operaval hasznalom (szokoevente egyszer), es ott mashogy megy a java;
de a logika hasonlo;
"a pax-on belul a non-exec-pages kozul semmi sincs bekapcsolja, ezeket be kéne akkor még az Xfree-sem fog elinudlni, legalábbis a help szerint, vagy nem ?"
en jopar honapja hasznalom szinte maximumon (lasd kernel_felkonfig a) resze) es csak a "pax felulbiralasa" reszben leirtakkal talakoztam; mondjuk nem kdet hasznalok;
a "disable privileged io" tenyleg kiaksztja az Xet;
"mert a sig11 loggolasa lehet a CONFIG_GRKERNSEC_SIGNAL bekapcsolasa miatt;"
magayrul a grsec csak azt loggolja, hogy vmi sig11-el elszallt, nem a grsec okozza a problemat (_elvileg_);
"grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (java_vm:710) UID(1000) EUID(1000), parent (mozilla-bin:701) UID(1000) EUID(1 000)"
ezt ki lehet kerulni egy 'ulimit -c unlimited'-del, de altalaban nem segit, mert egy programhiba resze;
grsec config ( most már minden benne van, most fordul, ha nem jövök egy darabig akkor nincs X )
CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CUSTOM=y
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=10000
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=4
CONFIG_PAX=y
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_NO_ACL_FLAGS=y
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_SEGMEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_NOVSYSCALL=y
igen benne van a logolás, ami érdekes hogy aztmondja hogy sig 11 el kinyirta a java-t de megsem történt meg, lehet hogy a paxctl miatt mert levettem róla mindent
az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
[quote:399b330afb="Oscon"][quote:399b330afb="selli"]PAX: execution attempt in: /dev/zero, 33c61000-33c62000 00000000
PAX: terminating task: /home/public/Games/Wolfenstein/wolf.x86(wolf.x86):27339, uid/euid: 1000/1000, PC: 33c61000, SP: 5f1a0ca8
PAX: bytes at PC: 55 8b ec 53 56 57 8b 75 08 8b 7d 0c 8b 6d 10 85 ed 0f 84 43
PAX: bytes at SP: 2b3235be 09cc57c8 09cc5bd0 00000010 5f1a0d6c 00000000 2b32cd1a 33951040 5f1a0d6c 09cc57c8 09cc5bd0 00000000 5f1a0d6c 09cc4ba0 2b32cccc 2b323588 00000001 2b32b305 33951040 5f1a0d6c
grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /home/public/Games/Wolfenstein/wolf.x86[wolf.x86:27339] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:27323] uid/euid:1000/1000 gid/egid:100/100
ez miért van ? ez normális? mi a magyarázat
( chpax -sp wolf.x86 megoldja)
Röviden az, hogy a progi (wolf3d) memóriakezelés szempontyából szarul van megírva.
A PAX a "memória" nemkívánatos területén észlelte, hogy a program "futtatni" akar. (execution attempt).
Ezért ezt a futtatási kérést kirúgta. (terminating task)...
A program azonban ezt meglehetősen rosszul viselte, és hirtelen extra erőforrásokat igényelt magának, amit a grsec nem nézett jó szemmel, (attempted resource overstep...) ezért kirúgta az egész progit úgy ahogy van.
hát akkor megérdemelte. :)
[quote:c24a29ab1f="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
ok
a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?
[quote:c1959c8dcd="Anonymous"]"nagyon jo ez a forum, jo elvagyok magammal, de fo hogy talaltunk megoldast"
engem erdekel a tema, irj batran;
"grsec 1.9.9h + 2.4.1"
hat ez nem ma volt...
a nagybetu engedejez, erre alapesetben nincs szukseged;
fellow
bocsi elírtam -)...helyesen grsec 1.9.9h + 2.4.18 (debian 14.3) verzió.
[quote:797b1a343d="Oscon"][quote:797b1a343d="Anonymous"]Fagyott a java_vm grsec alatt
kiadtam a
paxctl -pemrxs java_vm parancsot, most nem fagy ki
gondoltam kiprobalom:
paxctl -PEMRXS java_vm es meg mindeg nem fagy ???????????
ez normális ? a 2. parancs nem az elso inverze ? vagy most mivan ?
paxctl 0.2
2.6.5-grsec
chpax 0.6 tapasztalatok: (grsec 1.9.9h + 2.4.18):
chpax -mprsx /usr/X11R6/bin/XFree86
chpax -Mprs /usr/java/j2re1.4.*/bin/*
chpax -MpRs /opt/OpenOffice.org*/program/soffice.bin
chpax -MpRs /usr/bin/wine.bin
chpax -mPRs /usr/bin/gmplayer
Openoffice,gmplayer nekem muxik alapbol is, vagy igy stabilabbak ?
winex-el kuzdok
Mplayer tapasztalat:
ha a grsec-ben proc restricton van es a /proc/cpuinfo nem olvashato akkor a kovetkezo video-t nem jatsza le az mplayer-1.0-pre5:
http://www.hup.hu/~trey/Doom3/doom3_g4.avi
megoldas
chmod 555 /proc/cpuinfo
hatva valakinek jol jo az info ;)
mplayer: /usr/lib/libGL.so.1: no version information available (required by mplayer)
ezt irja ki, miért? ( ennek elenére muxik)
[quote:40566762cf="selli"][quote:40566762cf="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
ok
a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?
Leírás szerint 2.6-os ficsőr - én még 2.4ben élek -) -
Leírás alapján én yes-re tenném.
[quote:b9afc84412="Oscon"][quote:b9afc84412="selli"][quote:b9afc84412="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
ok
a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?
Leírás szerint 2.6-os ficsőr - én még 2.4ben élek -) -
Leírás alapján én yes-re tenném.
leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?
[quote:b2ea5caa82="selli"][quote:b2ea5caa82="Oscon"][quote:b2ea5caa82="Anonymous"]Fagyott a java_vm grsec alatt
kiadtam a
paxctl -pemrxs java_vm parancsot, most nem fagy ki
gondoltam kiprobalom:
paxctl -PEMRXS java_vm es meg mindeg nem fagy ???????????
ez normális ? a 2. parancs nem az elso inverze ? vagy most mivan ?
paxctl 0.2
2.6.5-grsec
chpax 0.6 tapasztalatok: (grsec 1.9.9h + 2.4.18):
chpax -mprsx /usr/X11R6/bin/XFree86
chpax -Mprs /usr/java/j2re1.4.*/bin/*
chpax -MpRs /opt/OpenOffice.org*/program/soffice.bin
chpax -MpRs /usr/bin/wine.bin
chpax -mPRs /usr/bin/gmplayer
Openoffice,gmplayer nekem muxik alapbol is, vagy igy stabilabbak ?
winex-el kuzdok
kérdés mi az alap!
chpax -v /...../gmplayer, stb...
paxtest nálad mit fut?
Nálam ez az "alap", ezzel nem ment, aztán lehet, hogy az 1.9.9h-s grsec még ilyen téren brutálisabb volt. -)
PeMRxS
[quote:a6203283cd="selli"][quote:a6203283cd="Oscon"][quote:a6203283cd="selli"][quote:a6203283cd="Anonymous"]az "emulate trampolines" elmeletileg csak libc5-os progiknal (kb 100 eve) kell, ezert folosleges;
meg a "help" szerint biztonsagi kockazatot rejt;
imho szedd ki;
ok
a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?
Leírás szerint 2.6-os ficsőr - én még 2.4ben élek -) -
Leírás alapján én yes-re tenném.
leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?
leírás alapján 2.6-osban ez a vsyscall ficsőr hoz némi gyorsulást, de leírás szerint ez a ficsőr az exploit gyártók "fegyvere" lehet.
Szerintem komolyabban nem fogod megérezni,. a 2.4-es kernelben pl. ez a ficsőr totál nincs meg, és nem panaszkodom a sebességre.
"a CONFIG_PAX_NOVSYSCALL: mi legyen y or n ?"
Y, hacsak nem debian sid alatt vagy, de ez benne van a kernel_felkonfigban;
hagyne irjam le nszer ugyanazt;
"Openoffice,gmplayer nekem muxik alapbol is, vagy igy stabilabbak ? "
ha siman mennek, akkor nem allitottad eleg erosre a paxot;
"winex-el kuzdok"
azzal lehet, mert gany az egesz; inkabb a winet eroltesd;
"mplayer: /usr/lib/libGL.so.1: no version information available (required by mplayer)"
letezik az /usr/lib/libGL.so.1?
egyebekent forgasd ujra az mplayert forrasbol;
"leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?"
elemeletileg minden lassit vmennyit, gyakorlatilag en meg nem vettem eszre;
fellow voltam, es mara exit;
ha vmi nem vilagos a kernel_felkonfig + elerhetosegem benne + topic cime;
----[ chpax 0.6 : Current flags for /usr/local/bin/gmplayer (PeMRxS) ]----
* Paging based PAGE_EXEC : enabled (overridden)
* Trampolines : not emulated
* mprotect() : restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : enabled
(erdekes mprotect nincs is beleforditva)
PAX: execution attempt from 192.168.1.2 in: /lib/libc-2.3.2.so, 210c1000-211f0000 00000000
PAX: terminating task: /usr/sbin/proftpd(proftpd):3112, uid/euid: 0/1002, PC: 21138d18, SP: 5b249470
PAX: bytes at PC: 8b 46 08 89 42 24 89 f0 83 c0 08 eb ba 81 7d ec ff 01 00 00
PAX: bytes at SP: 5b2494a0 080a674c 5b2499ec 5b2495b0 00000000 00000000 00000000 634f2035 00000000 00000610 211f49a0 211f3d24 211f49a0 211f49a0 5b2494c8 21137f1a 211f49a0 0000060c 5b2499b0 0000060c
Ha jól értem akkor a proftpd a libc-ben probált végrahajtani kódot. Ez most azt jelenti, hogy valaki megprobálta feltörni a gépet 192.168.1.2-ről( ami a szomszéd gép, és szerintem csak annyi volt, hogy windos-commander/ftp/ majd egyszercsak kifagy a wcommander könytárváltás után)
----[ chpax 0.6 : Current flags for /usr/sbin/proftpd (PeMRxS) ]----
* Paging based PAGE_EXEC : enabled (overridden)
* Trampolines : not emulated
* mprotect() : restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : enabled
Akkor most mivan?
van valakinek infoja arrol hogy egy ilyen majdnem full grsec mennyivel lassul ( 1,2 % elmegy sztmem)
[quote:f97955481b="selli"]van valakinek infoja arrol hogy egy ilyen majdnem full grsec mennyivel lassul ( 1,2 % elmegy sztmem)
a KDE2 (debian woody) indulásakor +5msp -t vettem észre.
Meg a boot is lassabb talán +5-10 msp-vel.
Futásidőben nem tapasztaltam lassulást.
Winex sz'tem fából vaskarika.
Akkor már inkább tiszta W2K/WXP és azon nyomassad dual bootról.
[quote:e9d17b05a7="selli"]----[ chpax 0.6 : Current flags for /usr/local/bin/gmplayer (PeMRxS) ]----
* Paging based PAGE_EXEC : enabled (overridden)
* Trampolines : not emulated
* mprotect() : restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : enabled
(erdekes mprotect nincs is beleforditva)
paxtest ?
http://www.adamantix.org/paxtest/paxtest-0.9.6.tar.gz
$ chpax -v /usr/local/bin/mplayer
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer (pemRxs) ]----
* Paging based PAGE_EXEC : disabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
ez is csak a binaris win32 codecek miatt kell;
es ugyanezeke a beallitasok vannak a doksimban;
"van valakinek infoja arrol hogy egy ilyen majdnem full grsec mennyivel lassul ( 1,2 % elmegy sztmem)"
imho a kerdesben van a hiba, mert win alatt sem azt kerdezed, hogy mennyit lassit egy viruskergeto, hanem, hogy mennyire hatasos;
en nem vettem eszre lassulast, bar nem a kdet es hasonlo csirivili dolgokat reszesitem elonyben;
a winex kozelebe sem er a winenak, raadasul mivel mindeki p2p szerzi be a binaris valtozatot, ezert iedalis egy rootkitnek;
javítanék egy csöppet.
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer
* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
sorry, de max beallitasok mellet (lasd kernel_felkonfig) ez nem jo (nalam):
$ chpax -z /usr/local/bin/mplayer
$ chpax -sm /usr/local/bin/mplayer
$ chpax -v /usr/local/bin/mplayer
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer (PemRxs) ]----
* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
$ mplayer vmi_ami_w32_kodeket_igenyel.wmv
Leállítva
$ cat /var/log/syslog | tail
May 10 20:43:13 localhost kernel: PAX: execution attempt in: <anonymous mapping>, 0857a000-08851000 00000000
May 10 20:43:13 localhost kernel: PAX: terminating task: /usr/local/bin/mplayer(mplayer):11863, uid/euid: 1000/1000, PC: 085a5a90, SP: bb733d74
May 10 20:43:13 localhost kernel: PAX: bytes at PC: 55 89 e5 52 b8 05 00 00 00 ba 2c 75 07 08 c1 e0 05 05 60 04
May 10 20:43:13 localhost kernel: PAX: bytes at SP: 00423386 cfcf9898 bb733e9c 00000000 087486e8 087490c8 087490c8 00000000 087486e8 bb733e9c 00417f3a 00000000 087486a8 08744528 33564d57 4691be9c 00914d00 468b993a 4691be9c 00000000
May 10 20:43:13 localhost kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /usr/local/bin/mplayer[mplayer:11863] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:15190] uid/euid:1000/1000 gid/egid:1000/1000
Hello,
Nem tudja valaki hogy mert fagy a mozilla ha java-s oldalt nezek meg ?
System Error ? Resource not available ( valami ilyesmi )
2.4.22-grsec
grsec elott jo volt.
Tippek ( nagyon surgos )
+info
grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (java_vm:710) UID(1000) EUID(1000), parent (mozilla-bin:701) UID(1000) EUID(1 000)
Oscon:
"Én a következőt javaslom a kernel_felkonvhoz:
(...)"
_hatalmas_ thx, at fogom nezni es beleirom + ugyis tervezek egy "akik nelkul ..." szekciot;
ma lesz egy kisebb frissites, de meg ezek nelkul;
selli:
"mprotect után sokkal jobb es meg az opengl is megy, pedig azt olvastam hogy nem fog. hmm ?????????????????????????"
ezt targyaljuk le;
tudtommal (es tapasztalatom szerint) csak a binaris nvidia meghajtohoz adott libGL.so-val problemazik;
nalad milyen libGL.so van fenn?
"chpax -Mps vagy mPS az erosebb."
'chpax -h' - a nagybetu bekapcsolja a pax ellenorzeset, a kicsi kikapcsolja adott dunkciora; hacsak nem "soft mod"ban futtatod a paxot (alapbol kikpacsolva minen ellenorzese, de bekapcsolhato), akkor csak arra kell koncentralni, hogy _kikapcsolja_ egy-ket ellenorzest bizonyos binarisokra;
"( chpax -sp wolf.x86 megoldja)"
errol van szo, nehany binarisnal felul kell biralni a paxot;
egyebkent udvozlunk az extra paranoiasok vilagaban; ugye van egy tukor a monitor vmelyik sarkaban? ;-)
Hogyan lehetne a pax-ot ideiglenesen likvidalni ?
leirom mirol lenne szo:
Van egy progi install ami onkicsomagolos es egy java_vm-et telepíit a /tmp/... -be es az probalja használni a további lepesekben. de ez koztudott hogy nem megy pax-val. Hogyan lehetne megcsinálni hogy az ujonnal létrejött(gondolom kicsomagolja a tmp-be) fajlok chpax -mps jojjenek letre.
A gradm-hoz sajonos lovesem sincs. :(
[quote:dfef2b9111="fellow"]Oscon:
"Én a következőt javaslom a kernel_felkonvhoz:
(...)"
_hatalmas_ thx, at fogom nezni es beleirom + ugyis tervezek egy "akik nelkul ..." szekciot;
ma lesz egy kisebb frissites, de meg ezek nelkul;
selli:
"mprotect után sokkal jobb es meg az opengl is megy, pedig azt olvastam hogy nem fog. hmm ?????????????????????????"
ezt targyaljuk le;
tudtommal (es tapasztalatom szerint) csak a binaris nvidia meghajtohoz adott libGL.so-val problemazik;
nalad milyen libGL.so van fenn?
"chpax -Mps vagy mPS az erosebb."
'chpax -h' - a nagybetu bekapcsolja a pax ellenorzeset, a kicsi kikapcsolja adott dunkciora; hacsak nem "soft mod"ban futtatod a paxot (alapbol kikpacsolva minen ellenorzese, de bekapcsolhato), akkor csak arra kell koncentralni, hogy _kikapcsolja_ egy-ket ellenorzest bizonyos binarisokra;
"( chpax -sp wolf.x86 megoldja)"
errol van szo, nehany binarisnal felul kell biralni a paxot;
egyebkent udvozlunk az extra paranoiasok vilagaban; ugye van egy tukor a monitor vmelyik sarkaban? ;-)
Sorban:
- Igen, Nvidia-s binárisos closed source-os cuccom van:
nvidia: module license 'NVIDIA' taints kernel.
0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496 Wed Jul 16
19:03:09 PDT 2003
igaz régi, de ez legalább nem fagy X-konzol-X vátáskor
- dehogy van soft mod :) annál parásabb vagyok.
"chpax -Mps vagy mPS az erosebb." tudom mit jelent (sejtem) , csak az nem tudom melyiket vegyem le(mintha nem lenne teljesen mindegy)
-tükör nincs de jó ötlet. :)
grsec kijöhetne már a 2.6.6-hoz... milyen gyakran frissitik?
megvan egy workaround:
az Addres Space Layout Randomizacin-ot ke kellet kapcsolni, mert igy a hibas programok konyebben elszalnak, es hat ugy a java-ban azert lehet bug boven.
azert mindenkinek kosz
[quote:5b990dc257="fellow"]sorry, de max beallitasok mellet (lasd kernel_felkonfig) ez nem jo (nalam):
$ chpax -z /usr/local/bin/mplayer
$ chpax -sm /usr/local/bin/mplayer
$ chpax -v /usr/local/bin/mplayer
----[ chpax 0.6 : Current flags for /usr/local/bin/mplayer (PemRxs) ]----
* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled
$ mplayer vmi_ami_w32_kodeket_igenyel.wmv
Leállítva
$ cat /var/log/syslog | tail
May 10 20:43:13 localhost kernel: PAX: execution attempt in: <anonymous mapping>, 0857a000-08851000 00000000
May 10 20:43:13 localhost kernel: PAX: terminating task: /usr/local/bin/mplayer(mplayer):11863, uid/euid: 1000/1000, PC: 085a5a90, SP: bb733d74
May 10 20:43:13 localhost kernel: PAX: bytes at PC: 55 89 e5 52 b8 05 00 00 00 ba 2c 75 07 08 c1 e0 05 05 60 04
May 10 20:43:13 localhost kernel: PAX: bytes at SP: 00423386 cfcf9898 bb733e9c 00000000 087486e8 087490c8 087490c8 00000000 087486e8 bb733e9c 00417f3a 00000000 087486a8 08744528 33564d57 4691be9c 00914d00 468b993a 4691be9c 00000000
May 10 20:43:13 localhost kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /usr/local/bin/mplayer[mplayer:11863] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:15190] uid/euid:1000/1000 gid/egid:1000/1000
nekem engedi lejáccani a (g)mplayerből valami.wmv-t...
de mplayerből is lejácca. igaz nekem régebbi mplayerem van, lehet hogy azért.
grsec acl nem ereszti ki netre, úgyhogy így védem ki a remote dó'gait...-)
-----------
paxtest 0.9.6 nálam ezt fussa:
Linux osconsfortress 2.4.18-gekaichromage #1 2004. máj. 9., vasárnap, 15.00.04 CEST i686 unknown
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : No randomisation
Heap randomisation test (ET_DYN) : 17 bits (guessed)
Main executable randomisation (ET_EXEC) : 16 bits (guessed)
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Killed
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed
sajnos a workaaround nem jo, a tomcat mar nem indul el, sz*r az egesz java. most szedhetem le a grsec-et :( :x
hát elég sz*rul állok :(
paxtest:
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 25 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Vulnerable
mprotect-tel tényleg nem mennek az opengl-es (nvidia) cuccok ?
Én a következőt javaslom a kernel_felkonvhoz:
1.
Deny writing to /dev/kmem, /dev/mem, and /dev/port = Y
Ez úgy tapasztaltam, hogy dosemuval sem kompatibilis.
Proc restrictions = Y
Itt is tapasztaltam inkompatibilitási problémákat. énszerintem jobba
PROC_USERGROUP yes, +PROC_GID (pl. 1010).
Így ha valakinél gond van, akkor őt csak be kell sorolni a példában szereplő 1010-es csoportba, a többiek maradnak letiltva.
A Thrusted Path executiont is mindenképpen be kellene kapcsolni, én szerintem itt úgy, hogy
TPE _ALL yes, TPE_GID (pl. 1013)...Aki a 1013-asban van, az futtatás szempontjából untrusted. Ez a következőkre jó.
Ugye ha a /home, és a /tmp könyvtárakat noexec-el csatolod be, akkor onnan nem lehet semmit futtatni, kivéve, hogyha
a /lib/ld-linux.so.2 /home/../binaris -al próbálod indítani. Ha a user benne van az untrusted csoportban (=megbízhatatlan), akkor
a bináris segmentation fault-al elszáll, és egy aranyos grsec log jelenik meg, hogy mikor melyik user akaródzott untrusted cuccost futtatni. szerintem baromi hasznos a TPE kár kikapcsolni.
Sőt, szerintem a socket restrictiont is be kéne kapcsolni.
A socket all gid (csoport) az, aki se nem kezdeményezhet hálózati kapcsolatot (socket), se nem indíthat hálózati szervízt (bind) Ebbe a GIDszámú csoportba soroljuk be a rootot. (=rendszergazda ne internetezgessen, és ne indítson server típusú cuccot)
A socket_server gidbe meg soroljuk be a usereket. userek ne indítgassanak servereket.
A socket_kliens gidbe azokat a "usereket" kell besorolni, akik nevében server daemonokat futnak.
Ők nekik nem biztos, hogy muszáj netezgetni. -)
[quote:05039359aa="Oscon"]Én a következőt javaslom a kernel_felkonvhoz:
1.
Deny writing to /dev/kmem, /dev/mem, and /dev/port = Y
Ez úgy tapasztaltam, hogy dosemuval sem kompatibilis.
Proc restrictions = Y
Itt is tapasztaltam inkompatibilitási problémákat. énszerintem jobba
PROC_USERGROUP yes, +PROC_GID (pl. 1010).
Így ha valakinél gond van, akkor őt csak be kell sorolni a példában szereplő 1010-es csoportba, a többiek maradnak letiltva.
A Thrusted Path executiont is mindenképpen be kellene kapcsolni, én szerintem itt úgy, hogy
TPE _ALL yes, TPE_GID (pl. 1013)...Aki a 1013-asban van, az futtatás szempontjából untrusted. Ez a következőkre jó.
Ugye ha a /home, és a /tmp könyvtárakat noexec-el csatolod be, akkor onnan nem lehet semmit futtatni, kivéve, hogyha
a /lib/ld-config /home/../binaris -al próbálod indítani. Ha a user benne van az untrusted csoportban (=megbízhatatlan), akkor
a bináris segmentation fault-al elszáll, és egy aranyos grsec log jelenik meg, hogy mikor melyik user akaródzott untrusted cuccost futtatni. szerintem baromi hasznos a TPE kár kikapcsolni.
Sőt, szerintem a socket restrictiont is be kéne kapcsolni.
A socket all gid (csoport) az, aki se nem kezdeményezhet hálózati kapcsolatot (socket), se nem indíthat hálózati szervízt (bind) Ebbe a GIDszámú csoportba soroljuk be a rootot. (=rendszergazda ne internetezgessen, és ne indítson server típusú cuccot)
A socket_server gidbe meg soroljuk be a usereket. userek ne indítgassanak servereket.
A socket
Tisztázuk:
ezt most server-re, vagy desktop gépre is ajánlod?
ha desktopra is akkor ez már parás :)
Azért az túlzás, hogy szarul állsz, mert nem rossz ez...
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Tisztázuk:
ezt most server-re, vagy desktop gépre is ajánlod?
ha desktopra is akkor ez már parás :)
a kettő nem mindig külön választható.
A linuxos desktopok egy jó része a mögötte levő winek számára átjáró, és local mail server, és samba is lehet egyben.
Sz'al ez nem mindig kettéválasztható. sok desktopot használnak egyben serverként vagy fordítva.-)
most tekintsünk el az itthoni gépemtőla, ami elég macerás.
Itt több lokális user is van.
magyar KDE-vel, mozillaval (elöttük junkbuster), mplayer-el, OOoval, hogy mindenki örüljön. engem kivéve ált. kattingatós userek.
A leveleket exim+fetchmail+procmail szortírozza közöttü(n)k, mivel adslhez jár több mail alias is ugyebár.
Ill. fut még egy egyelőre localhost listenen egy apache+php+mysqles daemonom is mer' azt meg tanulgatom, ill. tanulgatnám, csak hát valami mindég közbejön. ha majd eljutok benne addiig, hogy tudom már mire használni , akkor majd kinyitom kifelé is...
Ráadásul meg kiemelten paranoid vagyok, ha internetről van szó. ez talán baj? -)
[quote:3c6b6934c3="selli"]Hogyan lehetne a pax-ot ideiglenesen likvidalni ?
leirom mirol lenne szo:
Van egy progi install ami onkicsomagolos es egy java_vm-et telepíit a /tmp/... -be es az probalja használni a további lepesekben. de ez koztudott hogy nem megy pax-val. Hogyan lehetne megcsinálni hogy az ujonnal létrejött(gondolom kicsomagolja a tmp-be) fajlok chpax -mps jojjenek letre.
A gradm-hoz sajonos lovesem sincs. :(
erre van a softmode tobbek kozott.
[quote:58902b2e86="PaXTeam"][quote:58902b2e86="selli"]Hogyan lehetne a pax-ot ideiglenesen likvidalni ?
leirom mirol lenne szo:
Van egy progi install ami onkicsomagolos es egy java_vm-et telepíit a /tmp/... -be es az probalja használni a további lepesekben. de ez koztudott hogy nem megy pax-val. Hogyan lehetne megcsinálni hogy az ujonnal létrejött(gondolom kicsomagolja a tmp-be) fajlok chpax -mps jojjenek letre.
A gradm-hoz sajonos lovesem sincs. :(
erre van a softmode tobbek kozott.
Lecsekolom.
kosz
[quote:b0fc59ca30="Oscon"]Azért az túlzás, hogy szarul állsz, mert nem rossz ez...
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
mprotect után sokkal jobb :) es meg az opengl is megy, pedig azt olvastam hogy nem fog. hmm ?????????????????????????
CONFIG_PAX_NOELFRELOCS
CONFIG_GRKERNSEC_IO
kell nekem ?
[quote:9b4aeb18c9="fellow"]Oscon:
selli:
"mprotect után sokkal jobb es meg az opengl is megy, pedig azt olvastam hogy nem fog. hmm ?????????????????????????"
ezt targyaljuk le;
tudtommal (es tapasztalatom szerint) csak a binaris nvidia meghajtohoz adott libGL.so-val problemazik;
nalad milyen libGL.so van fenn?
Eddig 4496-os nvdriver volt, az meg elviselte az mprotect-et.
Most mar 5336-van az nem szereti.
most chpax -m -ezhetem a glxgear-t :)
kb ennyi
[quote:c148158e30="selli"]
CONFIG_PAX_NOELFRELOCS
CONFIG_GRKERNSEC_IO
kell nekem ?
1.9.9h-ban a noelfrelocs dangerousnak van jelölve.
Most olvasgatom az újban, és bár angolban nem vagyok egy nagy eresztés, de szerintem ne kapcsold be.
sz'tem még mindig könnyen lehet, hogy ha bekapcsolod, akkor mondjuk paxtest határára egyszercsak futás közben a linux kernel elszáll, és semmilyen parancsra a továbbiakban nem reagál, ill. init 0/6-ra ugyanez.
grkernsec_io új ficsőrnek tűnik, leírás szerint xserver nincs, ha bekapcsolod.
ha nem kell xserver, akkor sz'tem nyugodtan benyomhatod, de ha kell, akkor inkább ne.
"Openoffice,gmplayer nekem muxik alapbol is, vagy igy stabilabbak ? "
ha siman mennek, akkor nem allitottad eleg erosre a paxot;
>>majdnem fullos a config
"winex-el kuzdok"
azzal lehet, mert gany az egesz; inkabb a winet eroltesd;
>> nem megy 3d-s cuccok, egyébként már müxik
"mplayer: /usr/lib/libGL.so.1: no version information available (required by mplayer)"
letezik az /usr/lib/libGL.so.1?
egyebekent forgasd ujra az mplayert forrasbol;
>> grsec elott meg jo volt, (forrasbol telepítve)
"leirás alapján lassabb lesz valami töle, csak kérdés hogy érezhető-e ?"
>>elemeletileg minden lassit vmennyit, gyakorlatilag en meg nem vettem eszre;
nem is lassit sokat:
kernel comp. with make -j 3
without grsec
real 6m51.699s
user 6m26.915s
sys 0m24.574s
with grsec
real 6m59.487s
user 6m28.988s
sys 0m28.020s
startx
without grsec
27.67 sec
with grsec
28.34
ennyi szerintem nem szamit a pluss 10x biztonaghoz kepest. ;)
PAX: execution attempt in: /dev/zero, 33c61000-33c62000 00000000
PAX: terminating task: /home/public/Games/Wolfenstein/wolf.x86(wolf.x86):27339, uid/euid: 1000/1000, PC: 33c61000, SP: 5f1a0ca8
PAX: bytes at PC: 55 8b ec 53 56 57 8b 75 08 8b 7d 0c 8b 6d 10 85 ed 0f 84 43
PAX: bytes at SP: 2b3235be 09cc57c8 09cc5bd0 00000010 5f1a0d6c 00000000 2b32cd1a 33951040 5f1a0d6c 09cc57c8 09cc5bd0 00000000 5f1a0d6c 09cc4ba0 2b32cccc 2b323588 00000001 2b32b305 33951040 5f1a0d6c
grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /home/public/Games/Wolfenstein/wolf.x86[wolf.x86:27339] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:27323] uid/euid:1000/1000 gid/egid:100/100
ez miért van ? ez normális? mi a magyarázat
( chpax -sp wolf.x86 megoldja)
Akkor egy masik workaround
chpax -spemrx java
chpax -spemrx java_vm
es maris muxik a tomcat is :)
nagyon jo ez a forum, jo elvagyok magammal, de fo hogy talaltunk megoldast
:wink:
???
Oscon:
hatize, eddig azt hittem, hogy paranoias vagyok, de ne erts felre, de ez a socket restriction pillanatnyilag sok(k); majd kicsit kesobb ...
xdm: epp most rugtam ki egy csomo csomagot (deborphan + kezi valogatas), inkabb ezt is kesobb cserelnem le;
magyaritas?
en is gondolkodtam ezen, de per pillanat a kernel_felkonfigot kene "befejezni", majd a faqt, majd ... nos a 3. meg nem publikus; de koze lesz a debianhoz ;-)
"nincs frame buffer, ez egy nvidia bug utanaolvastam majd javítjak (hahaha ) ezert tertem vissza egy regire"
miota jo kis tnt2 vantarol fx5600ra valtottam nalam is rendetlekedik, pld _neha_ fagy 1024 felett, 16bit felett, stb stb; jo sok piszkalas utan kiderult, hogy a via apollo pro chipsetet nem epp ilyen modernebb kartyakhoz terveztek;
persze van megoldas: nv; ez is tud xv-t es ugyse jatszom sokat; enigma, lbreakout2, stb;
"wolkot nem használom, kéne?"
ha van kedved miert ne, van errol szo a kernel_felkonfigban;
"Akkor most mivan?"
problad meg -spm es reprudokalni a hibat;
ha nem eleg, nez szett a grsec forumon;
Valakinek működik
http://www.grsecurity.net :?:
:cry:
[quote:7533886aae="Vendég"]Valakinek működik
http://www.grsecurity.net :?:
:cry:
Vasárnap déltutántol nem jön be :( lehet feltörték ? gondolom grsec-es kernel fut rajta, vagy win2003 server hehe
[quote:875f92e593="fellow"]"nincs frame buffer, ez egy nvidia bug utanaolvastam majd javítjak (hahaha ) ezert tertem vissza egy regire"
miota jo kis tnt2 vantarol fx5600ra valtottam nalam is rendetlekedik, pld _neha_ fagy 1024 felett, 16bit felett, stb stb; jo sok piszkalas utan kiderult, hogy a via apollo pro chipsetet nem epp ilyen modernebb kartyakhoz terveztek;
persze van megoldas: nv; ez is tud xv-t es ugyse jatszom sokat; enigma, lbreakout2, stb;
"wolkot nem használom, kéne?"
ha van kedved miert ne, van errol szo a kernel_felkonfigban;
"Akkor most mivan?"
problad meg -spm es reprudokalni a hibat;
ha nem eleg, nez szett a grsec forumon;
nem hinném hogy chipset probléma: i845-ös chipset + gef2 ( nincs generációbeli különbség sem)
a logban ez van:
Badness in pci_find_subsys at drivers/pci/search.c:167
kernel: Call Trace: [<c02b46f6>] [<c02b472d>] [<c02b4540>] [<e0c82ee1>] [<e0b582af>
kernel: Badness in pci_find_subsys at drivers/pci/search.c:167
kernel: Call Trace: [<c02b46f6>] [<c02b472d>] [<c02b4540>] [<e0c82ee1>] [<e0b582af>
kernel: Linux version 2.6.5-grsec (root@sunset) (gcc version 3.2.3) #17 Tue May 11 17:0
nem fagy csontra mert van log + ssh kill X müxik
"problad meg -spm es reprudokalni a hibat;"
szerintem egyszerű bug a proftp-ben
"igaz régi, de ez legalább nem fagy X-konzol-X vátáskor"
99% framebuffer a bunos, kapcsold le;
http://fellow.linuxforum.hu/faq/faq-all.html#q1_4_11
"tudom mit jelent (sejtem) , csak az nem tudom melyiket vegyem le(mintha nem lenne teljesen mindegy)"
'chpax -v'
-M restrict mprotect()
-m do not restrict mprotect()
-P enforce paging based non-executable pages
-p do not enforce paging based non-executable pages
-S enforce segmentation based non-executable pages
-s do not enforce segmentation based non-executable pages
tehat az -mps _kikapcsolja_ ezt a 3 ellenorzest, az -MPS _visszakapcsolja_; mivel egy binaris alapallapotban PeMRxS beallitasokkal bir, ezer alapallapothoz kepest nem tudod erosebbre allitani;
"grsec kijöhetne már a 2.6.6-hoz... milyen gyakran frissitik?"
1-2 het;
enegem most jobban erdekel, hogy mi van a wolkkal...
oke, meg nincs uj release, de a fejlesztes is leallt?! ( http://sourceforge.net/mailarchive/forum.php?forum_id=8245 )
[quote:431e7acb33="selli"][quote:431e7acb33="Vendég"]Valakinek működik
http://www.grsecurity.net :?:
:cry:
Vasárnap déltutántol nem jön be :( lehet feltörték ? gondolom grsec-es kernel fut rajta, vagy win2003 server hehe
http://hu.grsecurity.net
Vendég:
"Valakinek mûködik http://www.grsecurity.net?"
mirror: www.hu.grsecurity.net
selli:
egyebekent bocs, nethez nincs tul sok kozom;
[quote:3663d5b6bb="fellow"]mivel egy binaris alapallapotban PeMRxS beallitasokkal bir, ezer alapallapothoz kepest nem tudod erosebbre allitani;
Ezzel vitába szállnék
chpax -X binaris --al még "erősebbre" is lehet állítani.
A tapasztalataim szerint a Return to function strcpy,memcpy-s kisérleteket is legyilkolja.
Esetleg hálózati serverekre külön érdemes lehet bekapcsolni.
(apache, stb.)
[quote:49da667ede="fellow"]"igaz régi, de ez legalább nem fagy X-konzol-X vátáskor"
99% framebuffer a bunos, kapcsold le;
http://fellow.linuxforum.hu/faq/faq-all.html#q1_4_11
"tudom mit jelent (sejtem) , csak az nem tudom melyiket vegyem le(mintha nem lenne teljesen mindegy)"
'chpax -v'
-M restrict mprotect()
-m do not restrict mprotect()
-P enforce paging based non-executable pages
-p do not enforce paging based non-executable pages
-S enforce segmentation based non-executable pages
-s do not enforce segmentation based non-executable pages
tehat az -mps _kikapcsolja_ ezt a 3 ellenorzest, az -MPS _visszakapcsolja_; mivel egy binaris alapallapotban PeMRxS beallitasokkal bir, ezer alapallapothoz kepest nem tudod erosebbre allitani;
"grsec kijöhetne már a 2.6.6-hoz... milyen gyakran frissitik?"
1-2 het;
enegem most jobban erdekel, hogy mi van a wolkkal...
oke, meg nincs uj release, de a fejlesztes is leallt?! ( http://sourceforge.net/mailarchive/forum.php?forum_id=8245 )
nincs frame buffer, ez egy nvidia bug utanaolvastam majd javítjak (hahaha ) ezert tertem vissza egy regire
wolkot nem használom, kéne? :oops:
Köszi a segítséget
Én nem tudom letölteni a tükrökről a gradm*.tar.gz-k digitális aláírásait. :cry:
Ez normális :?:
( Lehet hogy vmi "bűzlik Dániában" ? )
megint foglalkoztam egy kicsit a grsecurityvel:
egyreszt oscon kollega tippjeit (maj 10) lassan feldolgozom;
eddig egyetlen problema a tpe miatt az /usr/local/bin jogosultsagat kelett alltani (a-w, u+w);
masreszt picit teszteletem (debian sid):
1. CONFIG_PAX_NOVSYSCALL - meg mindig fagy boot elejen;
2. CONFIG_GRKERNSEC_KMEM - X, ha ujrainditom (ctrl+alt+backspace), akkor _neha_ sig11;
May 20 16:04:13 localhost kernel: grsec: attempted mmap write of /dev/[k]mem by /usr/X11R6/bin/XFree86[XFree86:20005] uid/euid:0/0 gid/egid:0/0, parent /usr/X11R6/bin
/xdm[xdm:19822] uid/euid:0/0 gid/egid:0/0
3. CONFIG_PAX_NOELFRELOCS - minden oke lenne, de az o/a pluginjei nem mennek , libnpp.so -val van problema; es a binaris nvidia drivert hasznalva az X is sig11, akkor mikor a libGL.so akar az nvidia.o -val kommunkialni meg a X felallasa soran (sorry, log most nem talalok, de XFree86.0.log itt akad el a GLX extension betoltesenel);
harmadreszt a javanak problema: az mprotect, a non-executable pages, a trusted path, stb en inkabb éeszdtem, ugyse szoktam semmire se hasznalni;
ezeket majd beleirom a kernel_felkonfigba, lesz egy kulon grsec resz mar;
chpax -Mps vagy mPS az erosebb. ( a tvtime nevu progi mindket beallitsasl muxik, de mps-sel nem) melyiket allitsam be?
oscon:
hat, a socket restriction lehet, hogy nem desktop gepekre talatak ki;
all -ba nem rakhatom a rootot, mert nalam o futtatja a daemonokat, es ...
klient-be sem rakhatom, mert akkor nem megy az apt;
May 21 07:45:40 localhost kernel: grsec: attempted connect by /usr/lib/apt/methods/http[http:4258] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/apt-get[apt-get:32479] u
id/euid:0/0 gid/egid:0/0
az usert nem rakhatom serverbe, mert az xfce4 nem indul;
May 21 07:39:56 localhost kernel: grsec: attempted bind() by /usr/bin/xfce4-session[xfce4-session:5706] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:163
44] uid/euid:1000/1000 gid/egid:1000/1000
mivel desktop gep, csak ez a ket tenylegesen hasznalt account van;
vszinuleg at lehet majd hidalni a problemakat, majd egy kicsit kesobb;
[quote:b1ccdb8924="selli"]chpax -Mps vagy mPS az erosebb. ( a tvtime nevu progi mindket beallitsasl muxik, de mps-sel nem) melyiket allitsam be?
mPS
Oscon:
"Ezzel vitába szállnék
chpax -X binaris --al még "erõsebbre" is lehet állítani."
oke, akkor felreertek vmit, mert a CONFIG_PAX_RANDEXEC helpjeben ez all:
"By saying Y here the kernel will randomize the base address of normal ET_EXEC ELF executables as well."
nalam ez ugy jott le, hogy ezentul _alapbol_ minden elf binarison rajta lesz a "randomize ET_EXEC base";
de az alapbeallitas valoban PeMR_x_S;
no, nalam itt ellentmondas van;
[quote:ec8203894d="selli"]PAX: execution attempt in: /dev/zero, 33c61000-33c62000 00000000
PAX: terminating task: /home/public/Games/Wolfenstein/wolf.x86(wolf.x86):27339, uid/euid: 1000/1000, PC: 33c61000, SP: 5f1a0ca8
PAX: bytes at PC: 55 8b ec 53 56 57 8b 75 08 8b 7d 0c 8b 6d 10 85 ed 0f 84 43
PAX: bytes at SP: 2b3235be 09cc57c8 09cc5bd0 00000010 5f1a0d6c 00000000 2b32cd1a 33951040 5f1a0d6c 09cc57c8 09cc5bd0 00000000 5f1a0d6c 09cc4ba0 2b32cccc 2b323588 00000001 2b32b305 33951040 5f1a0d6c
grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /home/public/Games/Wolfenstein/wolf.x86[wolf.x86:27339] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:27323] uid/euid:1000/1000 gid/egid:100/100
ez miért van ? ez normális? mi a magyarázat
( chpax -sp wolf.x86 megoldja)
Röviden az, hogy a progi (wolf3d) memóriakezelés szempontyából szarul van megírva.
A PAX a "memória" nemkívánatos területén észlelte, hogy a program "futtatni" akar. (execution attempt).
Ezért ezt a futtatási kérést kirúgta. (terminating task)...
A program azonban ezt meglehetősen rosszul viselte, és hirtelen extra erőforrásokat igényelt magának, amit a grsec nem nézett jó szemmel, (attempted resource overstep...) ezért kirúgta az egész progit úgy ahogy van.
"Én nem tudom letölteni a tükrökrõl a gradm*.tar.gz-k digitális aláírásait. "
nalam jon:
$ wget http://www.hu.grsecurity.net/gradm-2.0.tar.gz.sign
--01:28:38-- http://www.hu.grsecurity.net/gradm-2.0.tar.gz.sign
=> `gradm-2.0.tar.gz.sign'
IP keres?s www.hu.grsecurity.net... 195.70.51.137
Csatlakoz?s www.hu.grsecurity.net[195.70.51.137]:80-hoz... kapcsol?dva.
HTTP k?r?s elk?ldve, v?rom a v?laszt... 200 OK
Hossz: 189 [application/x-tar]
100%[====================================>] 189 --.--K/s
01:28:39 (1.80 MB/s) - `gradm-2.0.tar.gz.sign' lementve [189/189]
hat, a socket restriction lehet, hogy nem desktop gepekre talatak ki;
all -ba nem rakhatom a rootot, mert nalam o futtatja a daemonokat, es ...
klient-be sem rakhatom, mert akkor nem megy az apt;
Na itt jón egy nagy trükk:
INIT alatt létrejönnek a kapcsolatok. pl. adsl connect, stb...
de ha belépsz, és poff-al lekapcsolódsz, akkor már nem mehetsz vissza login után.
Az INIT alatt létrejönnek az iptables szabályok, de login után már nem férsz hozzá ahhoz sem.
(=tehát senki sem fogja a jól beállított iptables szabályokat félrebuzerálni)
Sz'al sz'tem nyugodtan mehetnek ALL-ba.
May 21 07:45:40 localhost kernel: grsec: attempted connect by /usr/lib/apt/methods/http[http:4258] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/apt-get[apt-get:32479] u
id/euid:0/0 gid/egid:0/0
Én a köv.-t csináltam meg. Módosított a /var/lib/dpkg /var/cache/apt..stb.
jogosultságokat, így userként futtatom az apt-get update; apt-get -d upgrade parancsokat.
Ill. a "cron-user" futtatja őket a user nevében, mer' lusta disznó vagyok.
Majd a "root-cron" futtatja durván 40 percre rá a mount -o remount,exec /tmp;
apt-get -y upgrade; mount -o remount,noexec /tmp; szkriptet.
Így a rendszergazdának nem kell neteznie egyáltalán.
az usert nem rakhatom serverbe, mert az xfce4 nem indul;
May 21 07:39:56 localhost kernel: grsec: attempted bind() by /usr/bin/xfce4-session[xfce4-session:5706] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:163
44] uid/euid:1000/1000 gid/egid:1000/1000
Nálam több account van, ezért kdm-et használok bejelentkezéskezelőnek.
(és a többi account miatt kde 2.2.2-t magyarítással). A pingvin is megmarad és
a kde is jóllakik.) néhány darab Attempted bind kdeinit ugyan megjelenik, de ettől még minden működik.
Esetleg próbálhatod az xdm+xfce-t, vagy?
-------------------
Arra gondoltam, esetleg a grsec funkcióit jó lenne teljesen "magyarítani" a Configure.help alapján.
Van pár dolog ami magától értetődő. socket restrictions, logging stb.
de pl. a Link, FIFO restrictions, PAX-t jó lenne magyarra ferdíteni...
nemreg kerult be sid ala egy uj libc6 verzio, ami tamogatja a sysvcall tiltasat;
glibc (2.3.2.ds1-14) unstable; urgency=low
(...)
- debian/patches/glibc232-remove-vsyscall.dpatch: Remove __ASSUME_VSYSCALL
to fix the system startup failure on the machine using PAX.
(Closes: #245563)
jelzem: valoban megy;
selli:
nalam 0440 es lejatsza igy is;
Fagyott a java_vm grsec alatt
kiadtam a
paxctl -pemrxs java_vm parancsot, most nem fagy ki
gondoltam kiprobalom:
paxctl -PEMRXS java_vm es meg mindeg nem fagy ???????????
ez normális ? a 2. parancs nem az elso inverze ? vagy most mivan ?
paxctl 0.2
2.6.5-grsec