grsec + mozilla + java

[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

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 ?

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

[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.

----[ 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

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?

[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

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)

???

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: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:

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;