grsec alternativa

otletek:
1. friss vanilla + friss pax;
2. vegigprobalgatod, hogy mi okozza a problemat: pageexec, segmexec, mprotect, majd egesz noexec;
3. imho vedd fel a kapcsolatot pageexec@ vagy grsecurity foruman;

[quote:67f6be1d34="selli"]Mivel a grsec fejlesztese le[fog]all(t)[ni]. Ezért gondoltam tájékozodom milyen alternatívák vannak. Ki mit fog használni, ha esetleg vége a grsec-nek ? (Pax az OKs)

Szerintem megy tovább a grsec, úgyhogy leállok a hegesztéssel.

A honlap ugyanis ismét a régi, eltűnt róla a vészriadó is...

A 2.6.6hoz már lehet hogy spender nem csinál grsecet, mert a 2.6.7már pre3nál áll.

[quote:3cff92b78a="Oscon"]a mirrorok úgyfest ilyen mélységig nincsenek tükrözve...

Ha a grsec. végleg eltűnik, akkor elküldöm mailben.úgyanis előrelátóan lementettem...-)

Úgy néz ki, hogy bezárt a bazár. =((( Legalábbis 7-e van, és tegnap óta nem elérhető az oldal. Paxteam tud valami biztatót mondani?
Oscon: elküldenéd mailbe a 2 pdf-et? ( gabor kukac gnulinux pont hu )

köszi előre is.

[quote:dfd780edbe="selli"][quote:dfd780edbe="nevergone"]Senki sem portol nekem 2.4.25 -re 2.0 -ás GrSec -et...?

ha nem lennék hozzá kevés meg meg is csinálnám, de hát ez huzosabb mint 2.6.5-rol 2.6.6.-ra hackelni.

Ha ezt használod, akkor sz'tem még kevésbé húzósabb lehet mint a 2.6.6/2.6.5-ös...

http://grsecurity.net/grsecurity-2.0-2.4.26.patch

Ha pedig ezt erre is rá tudnád portolni, akkor min. megszavazlak miniszterelnöknek...:)

[quote:0556cb9223="selli"]Ahhoz képes hogy allítolag él a project, sem a 2.6.6-hoz sem a 2.6.7-hez se hire se hanva a grsec-patch-nek. :(

A 2.6.6-hoz szerintem azért nem volt, mert

1. talán lehet azt mondani, hogy már megjelenésekor javába bugzott
2. pont akkortájt voltak gondjai spender@-nek

De ha elküldöd spender@-nek a hackelt grsec-et, talán kirakja...:?:

A 2.6.7-hez pedig, ha csak rápotolja, vanilla-tól számítva kb. 1-2hét, és kicsit később ha lesz vmi újítás.:!:

OFF: Én azt várom mikor adják már ki végre a 2.4.27-et, mert akkor jön ki a
debianos javított kernel is...Aztán akkor megpróbálom ráerőszakolni a 2.4.27-es 2.0(.1?)-es grsecet. hátha..(?)

"es adodt egy kep a problemarol http://web.axelero.hu/bot02/problem.jpg"
nincs veletlenul fenn a libc6-i686 csomag? tobbszor probaltam, de mindig sig11 a vege;

jea.

June 8, 2004
Thanks to many donations and several sponsors (check the sponsors page as I update it), grsecurity development will continue. To see what changes are planned for grsecurity in the near future, consult the future work section of my research paper entitled "Increasing Performance and Granularity in Role-Based Access Control Systems" available from the papers section.
(http://www.grsecurity.net/news.php)

Oscon: a 2.4.26os vanillára készült grsecet azért nem egy olyan nagy dolog 2.4.25re portolni. 2.4.18ra legalább már érdekes feladat :wink:
btw neked a vanilla 2.4.18ra kéne vagy a debianizál izére?

[quote:b71806b872="vmiklos"]Oscon: a 2.4.26os vanillára készült grsecet azért nem egy olyan nagy dolog 2.4.25re portolni. 2.4.18ra legalább már érdekes feladat :wink:
btw neked a vanilla 2.4.18ra kéne vagy a debianizál izére?

természetesen a "debianizál"-ra...

Ami miatt "feladtam", íme egy példa: (../net/unix/af_unix.c)

---------

A 2.4.26ban a patchelni kívánt rész így kezdődik:

if (u) ....
dentry = u->protinfo

ekkor jön a gr_handle_chroot_unix PLUSZ...

a 2.4.18-debianban kb. ugyanitt viszont fordítottan szerepel.

if (!u)....

(bár most az a vad ötlet jutott az eszembe, hogy
if (!u) utáni parancsot{ .... } -t kapcsos zárójelbe teszem, aztán else, aztán jön a patch kapcsos zárjelben, aztán return u;

--------

egy jó csomót "manuálisan" a patch környezet javításával szerintem meg tudom csinálni, de az ilyeneknél már elakadok.
Ha az ilyenekben számíthatok segítségre, akkor viszont belevágok, de anélkül nem merek, mivel totál nem tudok c-ben programozni, ezt a fenti vad ötletet onnan szedem, hogy hasonló feltételek c forrásokban if-else-return-al kb. így "néznek ki".

Örülök, hogy folytatódik a project...
Nem tudjátok, régebbi kernelekhez honnan lehetne letölteni a patch -et...? Nekem 2.4.25 -höz kellene, de az oldalon csak 2.4.26 -hoz van...

http://www.grsecurity.net/grsecurity-1.9.14-2.4.25.patch

Tényleg... most hogyan áll a project... abba lesz hagyva, vagy lesz pénz...?

[quote:ffcb6379ed="zsirfeka"]http://www.grsecurity.net/grsecurity-1.9.14-2.4.25.patch

valaki a 2.0 -ás GrSec -et nem portolná vissza 2.4.25 -re...? :)

[quote:8f61397537="nevergone"][quote:8f61397537="zsirfeka"]http://www.grsecurity.net/grsecurity-1.9.14-2.4.25.patch

valaki a 2.0 -ás GrSec -et nem portolná vissza 2.4.25 -re...? :)

miert is ragaszkodsz a 2.4.25-hoz?

Azt hiszem, hogy ez a thread obsolete. Folytatódik a Grsecurity fejlesztése.

[quote:c5a514b6f6="trey"]Azt hiszem, hogy ez a thread obsolete. Folytatódik a Grsecurity fejlesztése.

HTTPS. Volt. Ebben az idézetben javítva.

[quote:8a3d850910="zsirfeka"]miert is ragaszkodsz a 2.4.25-hoz?

Mert a többi program, amit használnék, csak ezzel működik együtt, a 2.4.26 -ot (még) nem szeresse...

[quote:e23365e76b="nevergone"][quote:e23365e76b="zsirfeka"]miert is ragaszkodsz a 2.4.25-hoz?

Mert a többi program, amit használnék, csak ezzel működik együtt, a 2.4.26 -ot (még) nem szeresse...

milyen programok? (csak kivancsi vagyok)

http://www.grsecurity.net/lsm.php

:twisted:

[quote:646a2bacf4="zsirfeka"]milyen programok? (csak kivancsi vagyok)

Erről -most- inkább nem nyilatkoznék. És nem azért, mert nem akarok... maradjunk annyiban, hogy ez az egyetemen futó egy kutatás/fejlesztés része, és mint ilyen, még nem publikus... sorry... :)

Na ennek egyes alkotóelemei csak 2.4.25 alatt mennek, ugyanis még csak az alá készítettük el... :)

[quote:b1258540b5="nevergone"][quote:b1258540b5="zsirfeka"]milyen programok? (csak kivancsi vagyok)

Erről -most- inkább nem nyilatkoznék. És nem azért, mert nem akarok... maradjunk annyiban, hogy ez az egyetemen futó egy kutatás/fejlesztés része, és mint ilyen, még nem publikus... sorry... :)

Na ennek egyes alkotóelemei csak 2.4.25 alatt mennek, ugyanis még csak az alá készítettük el... :)

ertem. kb. hasonlo valaszra szamitottam :D

[quote:8bd7c151ea="zsirfeka"]ertem. kb. hasonlo valaszra szamitottam :D

Csak tudod, ha most nekiállok egy eléggé félkész állapotban lévő kutatásról ugrálni, akkor nemkissé szétrúgják a seggem... :roll:

[quote:5810c5044b="selli"]A 2.6.x-ben bekeult security model-lek ről tud valaki valmi infot ? Mit tud ? Hogyan lehez használni ? Gondolom nem sokat ér!(?)

Ezt azért nem mondanám...Van akinek erre van szüksége...grsechez képest szerintem valamivel nehezebb az acl-t konfigolni.
Grsectől eltérő "filozófia" szerint "rakták össze.

Sec. model szintjén Mingo exec-shieldje került bele, illetve az NSA féle SELinux.(~LSM)
, ill. a "néhai" international cryptoapi+cryptoloop patch is bekerült a linux kernelbe.

Mingo exec-shieldje mennyit ér, az egy jó kérdés...
én a paxtestet szerettem volna ráengedni, de a woody már nagyon nem szereti a 2.6.x szériát, úgyhogy ez kimaradt.

SElinux konfigurálás innen:

http://www.nsa.gov/selinux/info/docs.cfm

http://www.nsa.gov/selinux/papers/policy.pdf

http://www.nsa.gov/selinux/papers/policy2.pdf

[quote:5ed6088ba6="nevergone"][quote:5ed6088ba6="zsirfeka"]ertem. kb. hasonlo valaszra szamitottam :D

Csak tudod, ha most nekiállok egy eléggé félkész állapotban lévő kutatásról ugrálni, akkor nemkissé szétrúgják a seggem... :roll:

(mondom, hogy ertem)

[quote:67990bd2de="Oscon"]
Mingo exec-shieldje mennyit ér, az egy jó kérdés...
én a paxtestet szerettem volna ráengedni, de a woody már nagyon nem szereti a 2.6.x szériát, úgyhogy ez kimaradt.

En megtettem annak idejen:

http://www.hup.hu/~trey/!admin/modules.php?name=News&file=article&sid=4412

http://marc.theaimsgroup.com/?l=linux-kernel&m=106469414008517&w=2

http://marc.theaimsgroup.com/?l=linux-kernel&m=106469485509000&w=2

[quote:53054913f9="nevergone"][quote:53054913f9="zsirfeka"]milyen programok? (csak kivancsi vagyok)

Erről -most- inkább nem nyilatkoznék. És nem azért, mert nem akarok... maradjunk annyiban, hogy ez az egyetemen futó egy kutatás/fejlesztés része, és mint ilyen, még nem publikus... sorry... :)

Na ennek egyes alkotóelemei csak 2.4.25 alatt mennek, ugyanis még csak az alá készítettük el... :)

Nem akarok beleugatni, de egy biztonsági szempontból finoman szólva aggályos kernelre építeni, mintha kissé baklövésnek hangzana. nem lenne eccerűbb a projektet force-port-olni 2.4.26-ra,ill. szerintem egy héten belül 2.4.27-re, aztán azt már lehet vinni, mert állítólag 2.4.27 után lezárják és új ficsőr már nem kerül bele...

kar lenne erte, egyik kedvenc projectem volt :-(
a 2 pdf engem is erdekelne, kirakom a quickstart.doc egyetemben;
(fellow_linuxforum_hu)

sajnos a wolk se nagyon szuperal mostanaban;

[quote:183408387a="Oscon"]Nem akarok beleugatni, de egy biztonsági szempontból finoman szólva aggályos kernelre építeni, mintha kissé baklövésnek hangzana. nem lenne eccerűbb a projektet force-port-olni 2.4.26-ra,ill. szerintem egy héten belül 2.4.27-re, aztán azt már lehet vinni, mert állítólag 2.4.27 után lezárják és új ficsőr már nem kerül bele...

Igazad van, ez nem is marad így... sőt, szeretnénk teljesen függetlenedni a kerneltől (amennyire lehetséges), és majd átállni 2.6.x -re. De míg csak fejlesztői fázisban van a dolog, addig nem nem ezen agyalunk, van még bőven tennivaló... :)

[quote:3bb3bc0e0c="trey"][quote:3bb3bc0e0c="Oscon"]
Mingo exec-shieldje mennyit ér, az egy jó kérdés...
én a paxtestet szerettem volna ráengedni, de a woody már nagyon nem szereti a 2.6.x szériát, úgyhogy ez kimaradt.

En megtettem annak idejen:

http://www.hup.hu/~trey/!admin/modules.php?name=News&file=article&sid=4412

http://marc.theaimsgroup.com/?l=linux-kernel&m=106469414008517&w=2

http://marc.theaimsgroup.com/?l=linux-kernel&m=106469485509000&w=2

Az első link magamfajta "hup-usereknek" nem igazán nyerő, de a többi ok.

Úgy tűnik hogy mprotect() ellen nem véd..:

these are 'vulnerable' by design. There can be legitimate reasons to
mprotect() any of these regions. And if an attacker has enough control
over the target to execute mprotect() with precise arguments then the game
is mostly over anyway. Does anyone know the rationale of these mprotect()
tests?

Ha jól fordítom - javíts ki ha tévedek - baromi gyönge angoltudásommal, akkor azért nem foglalkozik ezzel mingo, mert úgy gondolja, hogyha
egy támadó eljut addig, hogy paraméterzve tud futtatni mprotect()en át, akkor már nincs mit tenni.
És nem érti mi a valóságalapja ennek a tesztnek.

Hát nem'tom...

Én valahogy inkább PaXal értek egyet.Az ilyen non-exec,stb. védelmek, elsősorban a 'root' jogait hivatottak korlátozni.
tehát ha már valaki eljut addig, hogy rootot szerez, akkor még utolsó védelmi vonalként le lehessen ütni a jogait.

Illetve mi van azokkal a cuccokkal, melyek mondjuk setuid root-ot követelnek maguknak,
és kiakadnak a PaX restricted mprotect védelmétől (~ nyílván mert szeretnék "használni"(?).

[quote:74baa1e40a="trey"]http://www.hup.hu/~trey/!admin/modules.php?name=News&file=article&sid=4412

Trey, nem szúrtál el a paste-nál valamit?

Gyk (nyilván nem Trey) a jó link: http://www.hup.hu/modules.php?name=News&file=article&sid=4412...

(Bocs, csak hogy minőségi legyen az oldal, nem hagyhattam ki... ;-) )

[quote:fee2e3db56="selli"]Ha már nem fejleszti(k) tovább legalább az ujabb kernel-ekhez meg kene csinálni a patch-t.

2.6.6- ra 26(ha jol emléxem) hunk van :(
en nem merem meghacceklni mert felek hogy baj lesz

2.4.18-ra az 1.9.9h-2.420-at sikerült módosítanom, hogy menjen.

van egy kis időm, megpróbálom, de tesztelni nektek kell, mert
a woodyt nem fogom szétverni egy 2.6.6os kernelért.

[quote:b281628c18="trey"]http://www.hup.hu/~trey/!admin/modules.php?name=News&file=article&sid=4412

ehhez jelszót kér :(

[quote:6537d4157f="selli"]Ha már nem fejleszti(k) tovább legalább az ujabb kernel-ekhez meg kene csinálni a patch-t.

a napokban spender azt mondta az irc-n, hogy mar eddig annyi lovet kapott, hogy nem kell elmennie a nyaron dolgozni. elkepzelheto, hogy folytatja, csak meg nem frissitette a honlapot. vagy lehet, hogy nagyobb penzre var :-D

[quote:c6092877ef="selli"]Ha már nem fejleszti(k) tovább legalább az ujabb kernel-ekhez meg kene csinálni a patch-t.

2.6.6- ra 26(ha jol emléxem) hunk van :(
en nem merem meghacceklni mert felek hogy baj lesz

az nem sok. a 2.4.20-1.9.9h/2.4.18as trükkben vagy 50 volt fuzz-okkal együtt.
egyébként a offsetek is át kell nézni, mert a c-kben néha van ismétlődés.

volt olyan offsetes hunk succeded , ahol a patchelni szándékolt rész 3szor volt a kernelben
három különböző static...( akármicsodában)...az eredeti 2.4.20-asban a második került módosításra de
a patch offset miatt elcsúszott, és a 3.at módosított volna.

De a Makefile-s első két faileddel már kész vagyok...-))

ami így 0. ránézésre macerássabbnak tűnik, az a mem.c (hunk 6), az fs/binfmtelf hunk 4,6, és az exec.c, az init/main.c és talán a fork.c...

[quote:501482a7d7="trey"][quote:501482a7d7="selli"]Ha már nem fejleszti(k) tovább legalább az ujabb kernel-ekhez meg kene csinálni a patch-t./quote]

a napokban spender azt mondta az irc-n, hogy mar eddig annyi lovet kapott, hogy nem kell elmennie a nyaron dolgozni. elkepzelheto, hogy folytatja, csak meg nem frissitette a honlapot. vagy lehet, hogy nagyobb penzre var :-D

Azért befejezem, ha már belekezdtem -), inkább legyen egy jó spenderes , meg egy összekapart magamfajta, mint egysem.

OFF:
Ezeket láttátok?

http://www.grsecurity.net/~spender/researchpaper.pdf

http://www.grsecurity.net/~spender/resume.pdf

[quote:dea1590093="fellow"]kar lenne erte, egyik kedvenc projectem volt :-(
a 2 pdf engem is erdekelne, kirakom a quickstart.doc egyetemben;
(fellow_linuxforum_hu)

sajnos a wolk se nagyon szuperal mostanaban;

elkűttem neked is...bár sz'tem nem biztos hogy ki kéne rakni, de te tudod.
május 31.i dátummal jelent meg a grsec.neten ~spender "mappájában".

Azért szerintem még nem kellene temetést rendezni - bár kétségtelen, hogy az összkép nem pozitív -, végülis még pageexec sem költözött el.
A grsecurity.net pedig úgy tűnik, mintha túlterhelési gondokkal küzdene, mivel egyelőre nem 404et adott vissza.

Amúgy ez egy elég jónak tűnő mirror, az eddigi pax.*-ot is mentették.:

http://mirror.alldas.org/www.grsecurity.net

----------

hosszabb távra sz'tem esetleg lehetne egy patch-setet csinálni, amiben
mondjuk PaX+LIDS+RSBAC, vagy hasonló összesség lenne, és ezzel az együttessel egy grsecet talán már teljesen ki lehet váltani.

[quote:35141fd561="Oscon"]hosszabb távra sz'tem esetleg lehetne egy patch-setet csinálni, amiben
mondjuk PaX+LIDS+RSBAC, vagy hasonló összesség lenne, és ezzel az együttessel egy grsecet talán már teljesen ki lehet váltani.

Azért ne feledd, az RSBAC (ha jól van beállítva) messze kenterbe veri a grsec -et... igaz, az elöbbit beállítani is nehezebb, én is most próbálkozom vele... :)

De persze a GrSec is jó project... volt... :?: :!:

Senki sem portol nekem 2.4.25 -re 2.0 -ás GrSec -et...?

[quote:38891ba3fc="Oscon"]OFF:
Ezeket láttátok?

http://www.grsecurity.net/~spender/researchpaper.pdf

http://www.grsecurity.net/~spender/resume.pdf

Csak nekem nem megy a grsecurity.net, vagy nektek sem?

[quote:6a14c19e4a="nevergone"][quote:6a14c19e4a="Oscon"]hosszabb távra sz'tem esetleg lehetne egy patch-setet csinálni, amiben
mondjuk PaX+LIDS+RSBAC, vagy hasonló összesség lenne, és ezzel az együttessel egy grsecet talán már teljesen ki lehet váltani.

Azért ne feledd, az RSBAC (ha jól van beállítva) messze kenterbe veri a grsec -et... igaz, az elöbbit beállítani is nehezebb, én is most próbálkozom vele... :)

De persze a GrSec is jó project... volt... :?: :!:

grsecben volt még egy rakás korlátozó ficsőr az ACLen kívül.
Egyébként nekem a processz ACL nagyon bejött grsecnél.
még "Alkalmazásszintű tűzfalszabályokat" is be lehet(ett?) lőni vele
a processzek CAP* korlátai, meg erőforrásigénye, meg stb. mellett.

Az rsbaccal nem vagyok biztos benne, hogy ezt speciel meg lehet-e oldani, de - mivel grsec volt kéznél - nem igazán szorultam
rá, hogy elmélyeggyek benne.

[quote:436ac4f0fe="Oscon"]grsecben volt még egy rakás korlátozó ficsőr az ACLen kívül.
Egyébként nekem a processz ACL nagyon bejött grsecnél.
még "Alkalmazásszintű tűzfalszabályokat" is be lehet(ett?) lőni vele
a processzek CAP* korlátai, meg erőforrásigénye, meg stb. mellett.

Az rsbaccal nem vagyok biztos benne, hogy ezt speciel meg lehet-e oldani, de - mivel grsec volt kéznél - nem igazán szorultam
rá, hogy elmélyeggyek benne.

Hát ne tudd meg... RSBAC -ban olyan sokféle korlátozási lehetőség van, hogy csak vakarom a fejem, hogy akkor most ki kivel is van. Sokkal aprólékosabban és ügyesebben lehet vele korlátozni (vagy engedélyezni) az egyes dolgokat... :)

De majd remélem az ilyen téren nálam okosabbak is hozzászólnak... és elmondják a mizu -t... :)

[quote:4371a7649c="Anonymous"]megint él: http://grsecurity.net/

Köszi.. lekaptam, ami hiányzott...

folytattam a grsec hegesztését 2.6.6-ra, kicsit másképpen.(votl ma rá vagy 3/4-ed órám összesen)
A grsec-2.6.5-ösben levő PaX-ot 2.6.6-osra (a grsec részek maradnak 2.6.5ösek) cserélem, így kicsit tovább tarta a hegesztés, de "alaposabb" lesz talán.

helyzetjelentés (kernelfordításra még messze nem alkalmas, de talán selli gondjait megoldja az i386/vlinuz.S-sel..?, bár nem tudom, ő milyen vonalon indult el...)

patchlog: (eddig vagyok meg, az ia_32_binfmt.c-re ma már nem maradt időm.)

patching file Makefile
patching file arch/alpha/kernel/osf_sys.c
patching file arch/alpha/kernel/ptrace.c
patching file arch/alpha/mm/fault.c
patching file arch/i386/Kconfig
patching file arch/i386/kernel/apm.c
patching file arch/i386/kernel/cpu/common.c
patching file arch/i386/kernel/entry.S
patching file arch/i386/kernel/head.S
patching file arch/i386/kernel/ioport.c
patching file arch/i386/kernel/ldt.c
patching file arch/i386/kernel/process.c
patching file arch/i386/kernel/ptrace.c
patching file arch/i386/kernel/reboot.c
patching file arch/i386/kernel/setup.c
patching file arch/i386/kernel/signal.c
patching file arch/i386/kernel/sys_i386.c
patching file arch/i386/kernel/sysenter.c
patching file arch/i386/kernel/trampoline.S
patching file arch/i386/kernel/traps.c
patching file arch/i386/kernel/vmlinux.lds.S
patching file arch/i386/mm/fault.c
patching file arch/i386/mm/init.c
patching file arch/i386/pci/pcbios.c
patching file arch/ia64/ia32/binfmt_elf32.c
patching file arch/ia64/ia32/ia32priv.h
patching file arch/ia64/ia32/sys_ia32.c
patching file arch/ia64/kernel/ptrace.c
patching file arch/ia64/kernel/sys_ia64.c
patching file arch/ia64/mm/fault.c
patching file arch/mips/kernel/binfmt_elfn32.c
patching file arch/mips/kernel/binfmt_elfo32.c
patching file arch/mips/kernel/syscall.c
patching file arch/mips/mm/fault.c
patching file arch/parisc/kernel/ptrace.c
patching file arch/parisc/kernel/sys_parisc.c
patching file arch/parisc/kernel/sys_parisc32.c
patching file arch/parisc/kernel/traps.c
patching file arch/parisc/mm/fault.c
patching file arch/ppc/kernel/ptrace.c
patching file arch/ppc/kernel/syscalls.c
patching file arch/ppc/mm/fault.c
patching file arch/sparc/kernel/ptrace.c
patching file arch/sparc/kernel/sys_sparc.c
patching file arch/sparc/kernel/sys_sunos.c
patching file arch/sparc/mm/fault.c
patching file arch/sparc/mm/init.c
patching file arch/sparc/mm/srmmu.c
patching file arch/sparc64/kernel/itlb_base.S
patching file arch/sparc64/kernel/ptrace.c
patching file arch/sparc64/kernel/sys_sparc.c
patching file arch/sparc64/kernel/sys_sparc32.c
patching file arch/sparc64/kernel/sys_sunos32.c
patching file arch/sparc64/mm/fault.c
patching file arch/sparc64/solaris/misc.c
patching file arch/x86_64/ia32/ia32_binfmt.c
Hunk #2 FAILED at 365.
1 out of 2 hunks FAILED -- saving rejects to file arch/x86_64/ia32/ia32_binfmt.c.rej

"Olvassatok vissza a paxos problémákhoz lécci"
sidet es grsecet hasznalok, a beallitasok benne vanna a kernel_felkonfigban; olvasd vegig elejetol vegeig, ha vmi nem vilagos: irj;

[quote:25d6b24eeb="Anonymous"]Iranyvonal:
2.6.6-ra ranyomta a 2.6.5-grsec-et. es elkezdetem a *.rej-ek alapjan a hackelset. (sajnos idom nincs, mert a heten vizsgazom, utolso vizsga (allamvizsga elott) yeaah, lehet lesz diplomam ?))

plussz van egy szuz 2.6.6 kernelem
ha majd muxik akkor diff -unR-el csinálok egy patch-t ( persze addig lehet kijon a 2.6.7-es kernel es kezdhetem elorol, persze nagyobb tapasztalattal)

A masik ami most juttot eszembe, hagy a 2.6.5-os grsec-bol ki kene torolni a pax-os reszt. majd 2.6.6-ra ranyomni a 2.6.6-os orig pax-ot, majd a pax-nelkuli grsec-et. igy a jovoben lehetne használni az ujabb pax-os patch-eket a pax-mentes-grsec-kel.

Oscon te hogy indultal el?

Hát most úgy csinálom, hogy
tty1-ben nyitom meg a logot, tty2-ben a pax-2.6.6-patchot, tty-3ban a 2.6.5 grsec patcsot, tty4-ben a akarmi.c.orig-t ha kell, a tty5-ben pedig, ha majd nagyon megnyekkenek, akkor a 2.6.5-ösből a akarmi.c-t...

Aztán így váltogatok. page-down-okkal haladok párhuzamosan a grsecben és a paxban.
így egy pillantás alatt meg lehet állapítani, ha ugrik a kép/sor, akkor valahol változott. azt módosítom a grsecpatchban, és így haladok szépen lassan.

Sajnos a paxos részeket csak úgy cserélni, kidobni a grsecből sz'tem kissé bonyolult, ugyanis van jópár olyan c forrásfájl, amit mindkettő módosít. így az eredeti paxhoz képest a grsecben a pax módosítások minimum sorszám,stb. szerint máris elcsúsznak...
és ez eléggé megnehezíti, hogy csak úgy kidobálj a pacsból dolgokat.

[quote:6332375945="spymorass"]

Csak nekem nem megy a grsecurity.net, vagy nektek sem?

azóta már nekem se megy, pedig kellene róla a
http://pax.grsecurity.net/pax-linux-2.6.5-200405011700.patch , ahhoz hogy
a 2.6.6-os portot legalább a magam gányolt móggyán meg tuggyam csiná'ni... :?

Jelen állás szerint a traps.c-vel bezárólag már átsasoltam...
itt az eddigi cucc... aszittem gyorsabban haladok majd, de a head.S fuzz-os egy kicsit húzósabb volt számomra.
A traps.c-ig így kell hogy kinézzen a patchlog:

patching file Makefile
patching file arch/alpha/kernel/osf_sys.c
Hunk #4 succeeded at 1305 (offset -3 lines).
Hunk #5 succeeded at 1316 (offset -3 lines).
patching file arch/alpha/kernel/ptrace.c
patching file arch/alpha/mm/fault.c
patching file arch/i386/Kconfig
Hunk #1 succeeded at 394 (offset 4 lines).
patching file arch/i386/kernel/apm.c
patching file arch/i386/kernel/cpu/common.c
Hunk #1 succeeded at 320 (offset 1 line).
Hunk #2 succeeded at 519 (offset 1 line).
patching file arch/i386/kernel/entry.S
patching file arch/i386/kernel/head.S
Hunk #2 succeeded at 99 (offset 13 lines).
Hunk #3 succeeded at 111 (offset 13 lines).
Hunk #4 succeeded at 171 (offset 13 lines).
Hunk #6 succeeded at 400 with fuzz 2.
Hunk #8 succeeded at 501 (offset -10 lines).
Hunk #9 succeeded at 516 (offset -10 lines).

Eddig megvan. tudom van benne egy fuzz2, de annak is örülök, hogy így sikerült összekapálni. az offseteket átnéztem, de úgy tűnt, csak elcsúszott a sorszám, más nem változott a grsec. szempontyából, azt meg a patch -p1 -E úgyis korrigájja, úgyhogy ezzel nem foglalkoztam.

Hja, azért ha vki ráér és velem ellentétben konyít a C-hez / én ugyanis síkhülye vagyok hozzá /, nem árt ha átnézi...főleg a head.S-et...

Na sz'al eddig ennyi van.

[quote:9b05633f74="selli"]Mivel a grsec fejlesztese le[fog]all(t)[ni]. Ezért gondoltam tájékozodom milyen alternatívák vannak. Ki mit fog használni, ha esetleg vége a grsec-nek ? (Pax az OKs)

Én még egy jó darabig a grsec-et fogom használni, amíg nem találnak benne vmi súlyosabb bugot.

Az 1.9.4-es óta nem találtam róla semmilyen rosszaságot. - az pedig nem tegnap jelent meg.

Jelenleg 1.9.9h-t használok 2.4.18as debian kernellel.
Amíg a debian supportálja a woodyt, azt hiszem továbbra is ezt fogom favorizálni.
Aztán ha megjelenik a sarge várhatóan vmiféle 2.4.27-28-29es kernellel, akkor lehet, hogy
a 1.9.15/2.0x-t próbálom ráerőltetni ezekre.

Gondolom sokan áttérnek majd OpenBSDre ) (funkcionalitásban - ha jól olvastam obsd ficsőrökről, mert kipróbálni nem volt bátorságom, trey tutorialjai eléggé elrettentettek - az OBSD ficsőrjei válthatják ki leginkább a linux+grsec párosítást. Ill. Adamantixra.

Linuxon belül patch szinten a SELinux, RSBAC, aztán asszem nagyjából ennyi a felhozatal. Sz'al nincs nagy kínálat.

Bár ezek asszem nem nyújtanak process based ACL-t, ami szerintem baromira hiányzik a linuxból.

OFF:
Ha a grsecnek vége - azért még ne kezdjük temetni, remélem lesz valami, nagy kár lenne érte -, nem lennék meglepve, ha PaX átköltözne az Adamantixhoz.
(~ pax.adamantix.org).

[quote:d5cf4b8ad8="spymorass"]Csak nekem nem megy a grsecurity.net, vagy nektek sem?

Vannak ilyen mirrorok, pl. http://hu.grsecurity.net

[quote:c971f3a357="Oscon"]trey tutorialjai eléggé elrettentettek

elrettentettek? miert?

Egyebkent volt meg a grsec elott az OWL (openwall). azzal most mi van? (a Solar Designer fele)

http://www.openwall.com/linux/

Oscon írta :

Linuxon belül patch szinten a SELinux, RSBAC, aztán asszem nagyjából ennyi a felhozatal. Sz'al nincs nagy kínálat.

Ehhez hozzáfűzném még az LIDS-t.

PaX alternatívák : Openwall, exec-shield ( Molnár Ingó :wink: )

Selli nézegesd őket, oszt ha választottál érdekelne hogy meliket, s miért

[quote:5f151e2c73="trey"][quote:5f151e2c73="Oscon"]trey tutorialjai eléggé elrettentettek

elrettentettek? miert?

Egyebkent volt meg a grsec elott az OWL (openwall). azzal most mi van? (a Solar Designer fele)

http://www.openwall.com/linux/

Az OpenWall max. a PaXot válthatná ki, de a PaX buff. ov. védelemben szerintem jobb.
A "non-executable userstack area" védelmen kívül restricted /proc, FIFO, tmp, destroy shared segments, némi erőforráslimitáció (RLIMIT NPROC) és ezzel kifújt.

ranger:

igen, még van a LIDS is.

A PaXnak reméljük talán nem kell keresnünk az alternatíváját, az megmarad, csak max. elköltözik.

--------

OBSD elrettentésről mindjárt hosszabban...-)

[quote:84c1e9ef75="selli"][quote:84c1e9ef75="Oscon"][quote:84c1e9ef75="spymorass"]

Csak nekem nem megy a grsecurity.net, vagy nektek sem?

azóta már nekem se megy, pedig kellene róla a
http://pax.grsecurity.net/pax-linux-2.6.5-200405011700.patch , ahhoz hogy
a 2.6.6-os portot legalább a magam gányolt móggyán meg tuggyam csiná'ni... :?

Na sz'al eddig ennyi van.

a pax nekem megvan

http://people.inf.elte.hu/selli/pax-linux-2.6.6-200405182000.patch

szolj ha mar nem kell torlom.

mennyire legyunk batrak kiprobalni ? (desktop kep) ha a file-rendszer nem serul akkor mar jo :)

Törölheted...

Azt amit eddig csináltam, azt még nem lehet kipróbálni, mert a kerneled le sem fordul vele...
De már látom a 2.6.6-os PaX-ból, hogy majd azt is módosítani kell, ami eddig megvan...

Hmm...ha ez hamarabb megvan, nem kellett volna szí'nom a head.S-el...

...

Na, módosítottam a filet...még ezzel sem fordítható kernel, de ez afféle állapotjelzés, hogy "holjárok"...mondjuk ha PaXTeam megjelenne, hogy spender viszi tovább a projektet mint eddig, azonnal abbahagynám, mer' elég babra egy dolog, mint láccik is...-)

patching file Makefile
patching file arch/alpha/kernel/osf_sys.c
patching file arch/alpha/kernel/ptrace.c
patching file arch/alpha/mm/fault.c
patching file arch/i386/Kconfig
patching file arch/i386/kernel/apm.c
patching file arch/i386/kernel/cpu/common.c
patching file arch/i386/kernel/entry.S
patching file arch/i386/kernel/head.S
patching file arch/i386/kernel/ioport.c
patching file arch/i386/kernel/ldt.c
patching file arch/i386/kernel/process.c
patching file arch/i386/kernel/ptrace.c
patching file arch/i386/kernel/reboot.c
patching file arch/i386/kernel/setup.c
patching file arch/i386/kernel/signal.c
patching file arch/i386/kernel/sys_i386.c
patching file arch/i386/kernel/sysenter.c
patching file arch/i386/kernel/trampoline.S
patching file arch/i386/kernel/traps.c

[quote:3f29991f8d="trey"][quote:3f29991f8d="Oscon"]trey tutorialjai eléggé elrettentettek

elrettentettek? miert?

Hát úgy nagy vonalakban.

A telepítés az még úgy nagyjából menne, de ez a "MBR (=gondolom Master Boot Record) felosztogatása" mindenféle részekre meglehetősen riasztónak hangzik még sokadik olvasatra is.

Mondjuk ha dual-bootból indulok ki. mert ugy "próba/tanulás" esetén abból indulok ki.De azért valszeg ezzel még elbírnék.
Akkor az is eléggé elriaszt, hogy mindent forrásból rak fel. Ez nekem a gentooban se tetszik.
Sok csomi esetén 10 körmömet lerágom, mire fel tudok tenni valamit.

Itt az 1.1, az érthető, még 1.7-ig is.

Az 1.7 már nálam lehúzta a rolót. ez a külön rc.conf ról 20adik olvasatra is az jön le, hogy hátezmegmiaszösz.
Az 1.11-es fstab kimenet teljesen kínai.
mi a szösz ez a "ffs"??

akkor ugyanitt rc.local.conf, meg rc. securelevel meg gondolom egy csomó hasonló tökismeretlen cucc.
fentebb volt szó /etc/rc.conf-ról , most meg rc.local.conf, meg rc.securelevel. (és ez csak az rc initkezelés).
Ha belőttem az rc,conf-ot minek az rc.local.conf?, ill. fordítva...vagy függenek egymástól, vagy?
minek ehhez 3 file? - tudom, man afterbootban minden benne van, de én nagyon nem szeretek vakon beugrani a semmibe, hogy nem tudom hova érkezem.

1.13.: /etc/fbtab...na ez meg mi a szösz?

Erre az 1.14 is rátesz még egy lapáttal, hogy ne szerkesszek "olyan különleges fájlokat", mint pl. db, localtime,rmt fájlokat
A gond az, hogy ha eljutok addig, hogy van egy feltelepített, de beállítatlan OpenBSD-m, halovány fogalmam sincs, OpenBSD alatt mik számítanak különleges fájloknak még pluszban ezeken kívül. (~ persze, ha átszerkeztek egy filet, és utána a bsd megnyekken, akkor onnantól tudom hogy azt nem kellett volna, de így azért elég lutri, gondolom nem 2 darab file van a /etc/ben...-))

Ugye nekem a pwd.db, és a spwd.db sem mond semmit.

----------------------
Sz'al az összképem így az, hogy én elhiszem,hogy biztonságos, stabil rendszert lehet gyártani belőle, de hogy én elemi dolgokat nem leszek képes beállítani belátható időn belül a tutorial, manual, doksik alapján az egészen biztos.

A kernel fordításból meg az jött le, hogy van egy GENERIC kernel, és azt célszerű használni.
Innen viszont a többi teljesen kínai. Hogyha van egy generic kernel, és azt célszerű használni,mert ez az alapja a standard OBSDnek. ez eddig oké, de ha úgyis ez van fent, akkor miért építsem fel ugyanebből a GENERIC-ből ugyanazt?...Valahol biztos elvesztettem a fonalat...
tehát miért fordítsak GENERIC kernelt, ha egyszer úgyis az van fent. (~ mivel ez a standard OBSD alapja, gondolom a feltelepített rendszernek is ez az alapja.akkor meg minek?..meg ez, hogy 3 részből áll, ports, meg kernel, meg userland, ez is nekem eléggé kusza, akkor miért nincs egy forrás, miért szedték külön, ha úgyis függenek egymástól.)

Valami értelme biztos van ennek a kernelfordítósdinak, úgyhogy az a gyanum, hogy valahol itt is teljesen elvesztettem a fonalat.

----------------------

meg aztán ha jól értem, mindent forrásból szed le, és a gépen fordítja le, mint a gentoo.
gondolom akkor egy fullos telepítés is szintén napokat vesz igénybe. (~ kb. beleőszülök, mire
leforog egy rencer). ez nekem már a gentooban sem tetszik.

na sz'al nagy vonalakban ez az amiért "megriadtam".

En nem ertek obsdhez, csak a sok forditashoz annyit, hogy obsdbol nyilvan nem desktop gepet epitesz, hanem servert, ha pedig ez a helyzet, akkor nem kell ra x, kde/gnome, ooo, miegymas, es igy mar rogton nem annyira sok, amig a dolgok lefordulnak.

szerintem lesz valami modon folytatasa a dolognak, tul sokan hasznaljak ahhoz, hogy valaki ne kezdje el csinalni, legfeljebb egy kicsit mashogy.
annak idejen 2.2-nel, ahol ugye nem volt grsec, elpocsolgettem openwall+hap+pax+fp komboval (paxbol hasznaltam az execshieldet, openwallbol csak a fifo + egyeb dolgokat, mivel pax egyertelmuen jobb ilyen teren), de nem volt tul szorakoztato kezzel osszehekkelni ezeket ("csak" a rejecteket kell helyrehozni, semmi komoly haxolas, de borzalmasan idorablo)
remelem, hogy lesz valami helyette. tavaly aprilis elsejen, mikor kiraktak, hogy over, akkor majdnem bomboltem (aztan megkonnyebultem, mikor eszembe jutott,hogy 04.01. van)

[quote:01c7919535="onyx"]En nem ertek obsdhez, csak a sok forditashoz annyit, hogy obsdbol nyilvan nem desktop gepet epitesz, hanem servert, ha pedig ez a helyzet, akkor nem kell ra x, kde/gnome, ooo, miegymas, es igy mar rogton nem annyira sok, amig a dolgok lefordulnak.

Igaz...

Amúgy a W~X-et lehet valami módon paraméterezni, mint a PaX-t Linux alatt (chpax?)

[quote:7418cdcfc9="zsirfeka"]szerintem lesz valami modon folytatasa a dolognak, tul sokan hasznaljak ahhoz, hogy valaki ne kezdje el csinalni, legfeljebb egy kicsit mashogy.
annak idejen 2.2-nel, ahol ugye nem volt grsec, elpocsolgettem openwall+hap+pax+fp komboval (paxbol hasznaltam az execshieldet, openwallbol csak a fifo + egyeb dolgokat, mivel pax egyertelmuen jobb ilyen teren), de nem volt tul szorakoztato kezzel osszehekkelni ezeket ("csak" a rejecteket kell helyrehozni, semmi komoly haxolas, de borzalmasan idorablo)
remelem, hogy lesz valami helyette. tavaly aprilis elsejen, mikor kiraktak, hogy over, akkor majdnem bomboltem (aztan megkonnyebultem, mikor eszembe jutott,hogy 04.01. van)

1 héten(?) belül meglátjuk...

[quote:7277c51492="Oscon"]Hát úgy nagy vonalakban.

A telepítés az még úgy nagyjából menne, de ez a "MBR (=gondolom Master Boot Record) felosztogatása" mindenféle részekre meglehetősen riasztónak hangzik még sokadik olvasatra is.

Semmi nehéz nincs benne és egyébként sem OpenBSD újdonság ez... Gondolom Linux alatt sem 1 partíciód van.

[quote:7277c51492="Oscon"]Mondjuk ha dual-bootból indulok ki. mert ugy "próba/tanulás" esetén abból indulok ki.De azért valszeg ezzel még elbírnék.

Backupot csinálj a dolgaidról mielőtt romba döntöd a vinyó tartalmát! :D

[quote:7277c51492="Oscon"]Akkor az is eléggé elriaszt, hogy mindent forrásból rak fel. Ez nekem a gentooban se tetszik.
Sok csomi esetén 10 körmömet lerágom, mire fel tudok tenni valamit.

Semmi nehézség nincs benne, de ha mégse akarsz portsal vacakolni, szintén vannak előre lefordított csomagok, mint debianban...

[quote:7277c51492="Oscon"]Az 1.7 már nálam lehúzta a rolót. ez a külön rc.conf ról 20adik olvasatra is az jön le, hogy hátezmegmiaszösz.

Az 1.11-es fstab kimenet teljesen kínai.
mi a szösz ez a "ffs"??

akkor ugyanitt rc.local.conf, meg rc. securelevel meg gondolom egy csomó hasonló tökismeretlen cucc.
fentebb volt szó /etc/rc.conf-ról , most meg rc.local.conf, meg rc.securelevel. (és ez csak az rc initkezelés).
Ha belőttem az rc,conf-ot minek az rc.local.conf?, ill. fordítva...vagy függenek egymástól, vagy?
minek ehhez 3 file? - tudom, man afterbootban minden benne van, de én nagyon nem szeretek vakon beugrani a semmibe, hogy nem tudom hova érkezem.

Az hogy nincsen mindenféle csilli-villi felülettel eltakarva a lényeg, szerintem nem éppen baj... az rc fájlok pedig teljesen logikusak. fstab kimenetet max. akkor nem érted, ha nem akarod. Az ffs egyébként a fájlrendszer (fast filesystem), mi más lenne. Sz'al nem akarásnak nyögés a vége.

[quote:48b86d2004="hunger"][quote:48b86d2004="Oscon"]Az 1.7 már nálam lehúzta a rolót. ez a külön rc.conf ról 20adik olvasatra is az jön le, hogy hátezmegmiaszösz.

Az 1.11-es fstab kimenet teljesen kínai.
mi a szösz ez a "ffs"??

akkor ugyanitt rc.local.conf, meg rc. securelevel meg gondolom egy csomó hasonló tökismeretlen cucc.
fentebb volt szó /etc/rc.conf-ról , most meg rc.local.conf, meg rc.securelevel. (és ez csak az rc initkezelés).
Ha belőttem az rc,conf-ot minek az rc.local.conf?, ill. fordítva...vagy függenek egymástól, vagy?
minek ehhez 3 file? - tudom, man afterbootban minden benne van, de én nagyon nem szeretek vakon beugrani a semmibe, hogy nem tudom hova érkezem.

Az hogy nincsen mindenféle csilli-villi felülettel eltakarva a lényeg, szerintem nem éppen baj... az rc fájlok pedig teljesen logikusak. fstab kimenetet max. akkor nem érted, ha nem akarod. Az ffs egyébként a fájlrendszer (fast filesystem), mi más lenne. Sz'al nem akarásnak nyögés a vége.

Köszi.

Azért volt furcsa, mivel soha még csak nem is hallottam "fast filesystem"-nevű filerendszerrel...

Az hogy nincsen mindenféle csilli-villi felülettel eltakarva a lényeg, szerintem nem éppen baj... az rc fájlok pedig teljesen logikusak.

Aki megszokta, meg tudja, meg stb. annak nyílván igen.

Nekem az a "normális", hogy van a /etc/init.d/ abban vannak az indíócuccok
és a /etc/rc*.d/-ben levő "runlevel" symlinkek adják meg, hogy mi mikor fut.

Ezt el tudom úgy képzelni,hogy egy rc.conf-ban benne van, hogy mi mikor indul el.

De hogy minek az rc.local.conf külön, meg az rc.securelevel, az számomra rejtély!

És akkor még bőven ott van,hogy csak félve merek a /etc-ben levő konfigfájlokba nyúlni, mert ugye nem mindegyiket szabad szerkezteni.

Félre ne értsd, Én nem azt mondtam, hogy az OpenBSD így "rossz", csak azt, hogy nekem így riasztó.

particiós tábla

most akkor amit trey art az a gyakorlatban azt jelenti, hogy az Obsd csak szimpla külön particiókat ( pl reiserfs,ext3) hoz létre semmi extrát sem?

Tényleg LILO-val lehet használni?

tehát mondjuk hogy a LILO indítja mondjuk
other=/dev/hda8
label=openbsd
, ahol hda8=wd0a

[quote:0ce00a412f="Anonymous"]Izé mikor lesz már kijavítva az hogy sid-en és sarge-on nemmegy pax?

Nem tudom, de ha kikapcsolod a CONFIG_PAX_NOVSYSCALL opciot, akkor _fog_ bootolni. Ezzel egy ideig egyutt kell elni. Egyebkent ugy tunik haladtak vele egy kicsit, de messze nincs befejezve a javitas. A kovetkezo cimen tudod nyomonkovetni a bugot:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245563

[quote:149f1973c6="Anonymous"]
A masik ami most juttot eszembe, hagy a 2.6.5-os grsec-bol ki kene torolni a pax-os reszt. majd 2.6.6-ra ranyomni a 2.6.6-os orig pax-ot, majd a pax-nelkuli grsec-et. igy a jovoben lehetne használni az ujabb pax-os patch-eket a pax-mentes-grsec-kel.

Annyira nem egyszeru kirantani alola a PaX-ot; vannak olyan fajlok, amiket mindketten megvaltoztatnak, nameg ha jol tudom az osszes #define es tarsai at lettek irva CONFIG_PAX_DEF -rol CONFIG_GRSEC_PAX_DEF -re...

[quote:83767cde0b="buga"][quote:83767cde0b="spymorass"]Csak nekem nem megy a grsecurity.net, vagy nektek sem?

Vannak ilyen mirrorok, pl. http://hu.grsecurity.net

Hiába. =(
Akkor sem tudom megnézni, amit akartam. =(

http://hu.grsecurity.net/~spender/researchpaper.pdf 404

[quote:8dcc8c6118="selli"]lehet hogy en is elkezdem hackelni a 2.6.6-ot "from szkrecss"
az majd összevetjük a végén (márha sikerul vmit produkálni)

Nem olyan könnyű elrontani egyébként.

Ha egyáltalán lefordul a hegesztett kernel, akkor már nagyot nem bukhatsz.
Ha valami nem kóser, akkor error 1/2:vel úgyis leáll, a hegesztett akarmi.c fordításakor.
és kiderül egyből mit hiányol.

Pl. A legdurvább az volt, mikor mingo schedulerjét ráengedtem az említett agyonpacsált kernelre, és
az kiütött néhány p->niceval -t és task_nice(p)-re cserélte az összeset. És a fordításkor ez úgy ütött vissza, hogy
a grsec_chroot.c-ben a p->niceval -al nem tudott mit kezdeni, ezért hibával leállt. azt kicserélve task_nice(p)-re warning-al ugyan, de lefordult.

Szóval ha lefordul, és a paxtest működik rajta és jó eredményt ad vissza, a gradm is bekapcsol, és az is működik, ill. az nmap -O -v is kiadja az ip randomot, meg az egyéb "restriction"-ok is mennek, akkor már nagy gáz nem lehet.

Ezenkívül én első menetben csak egyet rontottam a 1.9.9h/2.4.18-as trükkön, amikor
a /proc/partitions fájlt véletlenül sikerült eltüntetni, és mivel ritkán használt "fájl"-ról van szó, ezért csak a partimage használatánál tűnt fel, hogy hiányzik. :lol:

egy endif sor asszem eggyel lejjebb került, mint kellett volna. viszont így rájöttem, hogy "baj" esetén hogyan tudok egy kernelfordítással "tetszőleges" fájlt eltüntetni a /proc-ról...:lol

[quote:cfb07bafed="spymorass"][quote:cfb07bafed="buga"][quote:cfb07bafed="spymorass"]Csak nekem nem megy a grsecurity.net, vagy nektek sem?

Vannak ilyen mirrorok, pl. http://hu.grsecurity.net

Hiába. =(
Akkor sem tudom megnézni, amit akartam. =(

http://hu.grsecurity.net/~spender/researchpaper.pdf 404

a mirrorok úgyfest ilyen mélységig nincsenek tükrözve...

Ha a grsec. végleg eltűnik, akkor elküldöm mailben.úgyanis előrelátóan lementettem...-)

[quote:2ec94199bb="selli"]Majdnem lefordul a sajat hack :)

GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD vmlinux
grsecurity: file not recognized: K?nyvt?r
make: *** [vmlinux] Error 1

ez tudja valaki mi lehet ???????????

nem kóser...

A tiszta 2.6.6os kernelen futtasd le ezt
(patch -p1 -E < grsec-hack-selli.patch) > grsechack.log

ha a logban van "fuzz", illetve hunk failed, akkor nincs kész a hack, és szinte biztos hogy nem fordul le.
ha csak offset van, vagy az sincs, akkor vhol elcseszted.
töltsd fel, és megnézzük. én legkorábban 2-3 napon belül vmelyik este...

van egyáltatlán "linux-2.6.6/grsecurity" könyvtárad?