Mentsük meg Grsecurity-t / PaX-ot

Fórumok

Sajnos megint bajba került a projekt, mint ahogy azt itt is olvasni lehetett. Bátorítok minden egyéni felhasználót az adakozásra. A cégek, akik a patch-et használják pedig fontolják meg a szponzorációt.

Ha mindenki belead havi 10 dolcsit, akkor szerintem közösségi alapon is számottevő összeg jöhet össze. Lásd fsn tégla projekt. Ami fontos, az fontos.

Kérem csatlakozzatok.

Üdv,
Dw.

Hozzászólások

Minden tiszteletem tenyleg, es en is szivesen hozzajarulok, mert hasznalom egy-ket gepemen, de vegyuk eszre, hogy itt nem egy egyszeri adomanyrol van szo, hanem folyamatos (ha ugy tetszik allando) atutalasrol. Ha 500 ember havonta 10 USD-t utalna at, az havi $5000 eves szinten $60e. Ez mondjuk Amerikaban egy normalis informatikai fizetes egy embernek, nem kiugroan sok, de nem is veszesen keves. 500 ember nyilvan hasznal grsec-et, kerdes hogy hajlando-e fixen ennyit utalni?!

Még mielőtt gyűjtésbe kezdesz, érdemes egy célt felállítani. Jelen esetben, hogy "mennyi lenne elég az első évre". Amíg nincs cél, addig elég nehéz azt elérni. A cél eléréséhez meg kellene kérdezni az érintetteket, hogy mennyi pénz fedezné a első évi fejlesztést. Ezzel kellene kezdeni szerintem. A jövő év végén szintén lehetne indítani új gyűjtést a következő évi fejlesztésre. Sokan - alapítványok, például a FreeBSD alapítvány is - ezt csinálja.

--
trey @ gépház

Teljes mértékben egyet értek. Ezért korábban küldtem is emailt a fejlesztőnek, ahol javaslok is két stratégiát hosszú távra. Az egyik példa egyébként az fsn tégla projekt volt, amit írtam neki. A másik pedig az alapítványi működés.
Mindjárt csekkolom jött-e válasz.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Javaslat egy levél elküldésére:

A levelet ki kellene egészíteni, amikor megvan a végleges verzió, akkor (megfelelő angolsággal) angolra lefordítani. Én vállalom az elküldését. Ki vállalja a fordítást?

--

A levél:

Címzettek: Linus Torvalds, Andrew Morton, LKML

Meg fog szűnni a grsecurity, hacsak...

Ahogy azt valószínűleg tudjátok, régóta létezik egy GPL licencű biztonsági megoldás a Linux kernelhez. A neve grsecurity [1]. Fő fejlesztője hosszú évek óta tartja karban a patcheket a 2.4-es és 2.6-os kernelsorozathoz. A grsecurity meglehetősen hosszú feature listával [2] rendelkezik.

A fejlesztők szerint a patch olyan előremutató elgondolásokat tartalmaz a biztonság terén, amely több projektet is inspirált [3].

Egy héttel ezelőtt megjelent a grsecurity legfrissebb - és egyben lehetséges, hogy az utolsó - kiadása. A fő fejlesztő a gazdasági válság miatt elveszítette az egyetlen szponzorát, így kétséges a projekt jövője. Ezzel együtt a grsecurity egyik meghatározó komponensének, a PaX [4] publikus fejlesztésének is kétségessé vált a folytatása [5].

A múltban több kérés is irányult a grsecurity és a PaX mainline kernelbe való beolvasztására [6][7][8], sikertelenül.

A grsecurity, a PaX fejlesztőjének és felhasználóinak egybehangzó véleménye, hogy a megoldás megmentésének egyik lehetséges módja - megfelelő szponzor találásán kívül - a mainline kernelbe olvasztása lenne.

Mielőtt a projekt valóban végleg eltűnik, megkísérlem újra felhozni a beolvasztás témát.

Szeretném megtudni, hogy valóban nincs-e esély arra, hogy a grsecurity és / vagy a PaX a mainline kernel része legyen valaha és ha nincs, akkor mik azok az ésszerű okok, ami miatt lehetetlen a beolvasztásuk.

Köszönettel:

[1] http://www.grsecurity.net
[2] http://www.grsecurity.net/features.php
[3] http://grsecurity.net/~spender/grsecurity_pax-influence.png
[4] http://pax.grsecurity.net/
[5] http://www.grsecurity.net/news.php#grsec2112
[6] http://lkml.org/lkml/2003/4/20/13
[7] http://lkml.indiana.edu/hypermail/linux/net/0602.0/0020.html
[8] http://lkml.org/lkml/2005/1/13/184

--
trey @ gépház

Grsecurity is about to be discontinued, unless...

As most of you probably know, a GPL licensed security solution called grsecurity has been available for the Linux kernel since a while. [1] It has a rather impressive list of features. [2] The lead developer has been maintaining patches for the 2.4 and the 2.6 branch since many years.

According to their developers, the patch includes various advanced security aspects which inspired several further projects. [3]

A week ago, the latest - and probably the last - release was published. The main developer lost its sole sponsor due to the financial crisis, so the future of the project is in danger. As a result, the future development of PaX, one of the definitive components of grsecurity is also in deep trouble.

In the past, there have been several requests toward the Linux developers to include grsecurity and PaX in the mainline kernel, but in vain. [6][7][8]

The common opinion of the developers of grsecurity, PaX and their users is that acceptance of the code into the kernel would be the best solution for saving the project, beside finding another long-term sponsor.

Before the project would finally die, I would like to draw your attention to the question of integration into the kernel again.

In short, I would like to know what is your answer to this request. And in the case if you see no chance for the integration, I would like to know what is the reason behind this decision.

Thanks and best regards,

Ez kicsit olyan, mint amit a napokban kaptam: a Novell felkért egy fordítási tesztelőt, hogy köpködje meg az aktuális suse honosítását. Talált is jópár olyat, hogy eltér az iparági szabványtól (=MS :)), és hogy változtassunk. Jó, de akkor verjük végig mind a ~100 modulon, csak a következetesség nevében. Részemről elvileg még mehetne is (pl forward=előre->tovább, mégsem->mégse), de ez valahogy akkora melónak tűnik, amihez se időm, se kedvem. Persze hogy send patch üzemmódba kapcsoltam magam, de gondolom sejted mikor kapok konkrét peccset attól, akit a hibakereséssel (és nem a javítással) bíztak meg.

Valahogy itt is ezt a máséval a csalánt effektet érzem, főleg a [8] jelű Linus-levél tükrében, ilyetén formán most borítékolnám, hogy mit fognak reagálni: vannak részek amiről tárgyalhatunk, de send individual patches, meg vannak amikről nem, de ahhoz is send individual patches.

Hát igen. Linus nem hazudtolja meg magát. Az meg mellékes, hogy a closed-source Adobe flash pluginnal naponta sikerül begyűjteni execution attempt-eket (tegnap: ikea és ebay).

De a mainline szerintem nem mentené meg akkor sem a projektet. Az már annál inkább, ha az OSF foglalkoztatná Brad Spenglert és PaXTeam-et.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Én az egyik hivatkozott threadet olvastam el 2005-ből, ahol Mingo elég jól leírta az álláspontját, hogy neki (mint RedHat fejlesztő) mi volt a problémája a PaX-szal.
Nem értek hozzá, de a 3 dolog, amiket felhozott teljesen értelmesnek tűntek a RedHat szempontjából:

- a processzek számára elérhető memória felére csökkenése (3G -> 1.5G): ez RedHat számára probléma, ha van olyan alkalmazás fizető klienseknél, ami ennél többet igényel.

- az implementáció komplexitása: ezen nyilván lehet vitatkozni, szerintem ez némi lélekápolással megoldható lett volna.

- exception list kézi karbantartása: jól látszik, hogy az ő megoldásuknak (exec-shield) az automatikus kivételfelderítés volt az egyik általuk kitalált "killer" feature. Ennek természetesen fontos gyakorlati jelentősége volt számukra a disztribúció fejlesztése / támogatása szempontjából.

Azt Mingo elismerte, hogy a PaX teljes védelmet nyújt, míg az exec-shield nem. Viszont az ő (RedHat) követelményeiknek az exec-shield jobban megfelelt. A levelekből határozottan az az érzésem, hogy ha a fenti problémákra megoldásokat lehetett volna találni, akkor a RedHat/Mingo nem ellenezte volna a beolvasztást. Azt persze nem tudom, hogy a fenti problémák idő közben megoldásra kerültek-e, és milyen volt ezeknek a javításoknak a fogadtatása.

Nekem Linus mostani válaszából is úgy tűnik, hogy lehetőség lenne a Grsec / PaX jelentős részének beolvasztására, ha a Grsec / PaX fejlesztők hajlandók együtt dolgozni (szétszedni a patcheket triviális részekre, egyenként az összes review problémát türelmesen megvitatni...stb.)

Ez persze nem érdekes munka, sok idegeskedéssel/levelezéssel és kevés kódolással jár. Ugyanakkor egy ilyen átírás/review kör véleményem szerint javíthatja a kód minőségét.

Üdv,
Gergely

"Nekem Linus mostani válaszából is úgy tűnik, hogy lehetőség lenne a Grsec / PaX jelentős részének beolvasztására, ha a Grsec / PaX fejlesztők hajlandók együtt dolgozni (szétszedni a patcheket triviális részekre, egyenként az összes review problémát türelmesen megvitatni...stb.)

Ez persze nem érdekes munka, sok idegeskedéssel/levelezéssel és kevés kódolással jár. Ugyanakkor egy ilyen átírás/review kör véleményem szerint javíthatja a kód minőségét."

Ugyanezeket mondtam én is a #hup.hu-n. Ott az volt az egyik válasz, hogy talán már nem is akarják a Grsec fejlesztői a beolvasztást.

--
trey @ gépház

Nekem nem úgy tűnik, hogy Linus szeretné a beolvasztást. Mások a biztonságról alkotott elképzelései. Dehát ezt régóta tudjuk.
Nem tudom mi lenne, ha jönne egy ultimate exploit. Sok embernek újra kéne definiálni a biztonsági koncepcióját.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nem gondolom, hogy Linus hozzáállásán múlik a Linux rendszerek biztonsága.

Pl. ha valakit zavar, hogy nincs nagy "SECURITY SECURITY SECURITY" matrica minden biztonsági hibával összefüggő commiton, az simán megteheti, hogy indít egy mashup szolgáltatást, ahol az egyes git commitokhoz linkelni lehet a CVE-ket PoC exploitokat...stb.

Hozzátenném, hogy az szerintem is kellemetlen, ha egy általuk definiált "full disclosure" policyt nem tartanak be. Ha nem kívánják betartani, akkor mondják meg nyiltan, biztos lesz (van?) olyan, aki a fenti szolgáltatást megcsinálja.

Linusnak van egy jól meghatározott (nyilván objektív és szubjektív) követelményrendszere, hogy mit akar a mainlineban látni. Azt is látni kell, hogy van egy nagyon erős bizalmi alapon épülő kapcsolati háló Linus körül. Ezen a hálón alapszik a Linux kernel fejlesztése. Pl. ha "meg tudod szerezni" Mingo, GregKH és Andrew Morton signoffját a patchedre, nagyon valószínű, hogy be fog kerülni.

Azon lehet végtelen vitákat folytatni, hogy ezek a kulcspozícióban levő fejlesztők megfelelőek-e a feladatra. Jelenleg élvezik mind a fejlesztők többségének, mind a Linux iparban fontos szerepet játszó cégeknek a támogatását.

Üdv,
Gergely

a processzek számára elérhető memória felére csökkenése (3G -> 1.5G)

Ez igazabol 1 feature a sok kozul (SEGMEXEC), ami:
- kikapcsolhato, ha nem tetszik
- ha kikapcsolod, van helyette mas (PAGEEXEC), ami ugyanazt tudja, max. lassabban
- NX flages procikon mar ugysem hasznalja senki
- x64-es procikon meg mar nem is lehet (leven hogy nem tudnak szegmentaciot)

Szerintem ez manapsag mar nem jo ellenerv.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Tehát akkor a végleges verzió?

--

Grsecurity is about to be discontinued, unless...

As most of you probably know, a GPL licensed security solution called grsecurity [1] has been available for the Linux kernel since a while. It has a rather impressive list of features [2]. The lead developer has been maintaining patches for the 2.4 and the 2.6 branch for many years.

According to their developers, the patch includes various advanced security aspects which inspired several further projects [3].

A week ago, the latest - and probably the last - release was published. The main developer lost its sole sponsor due to the financial crisis, so the future of the project is in danger. As a result, the future development of PaX [4], one of the definitive components of grsecurity is also in deep trouble [5].

In the past, there have been several requests toward the Linux developers to include grsecurity and PaX in the mainline kernel [6][7][8], but in vain.

The common opinion of the developers of grsecurity, PaX and their users is that acceptance of the code into the kernel would be the best solution for saving the project, beside finding another long-term sponsor.

Before the project would finally die, I would like to draw your attention to the question of integration into the kernel again.

In short, I would like to know what is your answer to this request. And in the case if you see no chance for the integration, I would like to know what is the reason behind this decision.

Thanks and best regards,

[1] http://www.grsecurity.net
[2] http://www.grsecurity.net/features.php
[3] http://grsecurity.net/~spender/grsecurity_pax-influence.png
[4] http://pax.grsecurity.net/
[5] http://www.grsecurity.net/news.php#grsec2112
[6] http://lkml.org/lkml/2003/4/20/13
[7] http://lkml.indiana.edu/hypermail/linux/net/0602.0/0020.html
[8] http://lkml.org/lkml/2005/1/13/184

--
trey @ gépház

Épp most olvasok egy hírt a JPG magazin megszűnése kapcsán, meg ötleteket a kommentekben, hogy a megszűnés rémhírével tulajdonképpen könnyebb befektetőket találni, erre idekattintok és legfelül mi van? Ez a topik.
(Bár... A webisztánt olvasgatva egy nagyon előtérbe nyomott spekulálós amatőrökből álló csapat képe jelenik meg előttem akik szakmainak akarnak tűnni a webkettősítő hájpgépezetben. Mit tudhatnak ők az opensource működéséről?)

Én, személy szerint ehhez a kezdeményezéshez nem sok reményt fűztem, (ahogy látom, mások sem), de persze megpróbálni jó volt.

Örülnék, ha a grsecurity egészéből, de minimum a Paxból bizonyos részek legalább bekerülnének a kernel fősodrásába, és úgy látom, ettől nem is zárkózik el Linus.

Persze fogalmam sincs, hogy mennyire vehető ki egy-egy darabkája a cuccnak, de felteszem a Hunger által szapult randomizációs részt felülcsapni a Pax randomizációs részével pl. megtehető lenne.

Jó lenne találni a többitől függetlenül működtethető, magában is értelmes (tehát valami célt elérő) részeket.

De amit igazából kérdezni akartam:

Nem lenne szerintetek jó ötlet írni valakinek (valami cégnek, vagy társaságnak), hogy hé, itt ez a projekt, bajban van, szerintünk jó ötlet lenne, ha segítenétek rajta...

Pl. az Ubuntu jutott eszembe, elméletileg annak a Mark gyereknek van mit a tejbe aprítania (mert egyébként a Debian is eszembe jutott, de szerintem nekik nincs tőkéjük. Nem?).

Szóval pl. valami olyasmit gondolnék, hogy:
Kedves Márk! Itt ez a projekt, ami tök jó, viszont a fejlesztőknek nem sikerült elérniük a vanília kernelbe kerülést, külön meg már nem tudják csinálni tovább.
Arra gondoltunk, milyen jó lenne, ha az Ubuntu felkarolná a projektet, és először csak a disztribúcióban alapból szállítana grsec-kel biztonságosabbá tett kernelt (esetleg csak az ubuntu szerver változatában alapértelmezetten, a többi változatban csak választhatóan), később pedig segítene a projekt darabonkénti elfogadásában...

Mert az a véleményem, (úgy, hogy persze a kódrol fogalmam sincs), hogy igaza van Linusnak az ő oldaláról, és nem tudom, mi a véleménye a grsec csapatnak, de láthatóan nem sikerült a beolvasztás irányába lépni, Linus azt írta, hogy nem kapott egy fia különálló foltot sem.

Szóval ha mondjuk az adott cégnél lenne egy ember, aki eléggé kompromisszumkész, és tudja az erős egyéniségeket kezelni, talán ügyesen rábeszélhetné a fejlesztőket, hogy fűrészeljenek ki darabokat az egészből, és ugye ami már bekerül a fősodorba, azt már sokkal egyszerűbb (és olcsóbb) karban tartani.

Vagy ez így hülyeség?

G

Ha te mondod, az kellőképp hiteles. (Lehet hogy csak nekem tűnik a történés amolyan hattyú halálának, műbalhénak, az idézett példához hasonló szponzorszerzésnek. Közben lehet hogy tényleg eltűnik a cucc a süllyesztőben ha azok akik használják, nem tesznek érte. Ez a beolvasztásos dolog eddig nem jött be.)

Lehet, hogy butaság, de én arra várnék, hogy pl. Paxteam írjon egy postot, hogy egyáltalán nekik mi a véleményük, vagy ilyesmi.

Persze lehet, hogy nyaral, vagy ilyesmi, de jó lenne legalább valamit látni.

A másik fele: ém nem erőltetném azt, hogy egészben kerüljön bele, hipp-hopp, mert mi kérjük.
Linus válasza (a mostani) teljesen értelmes volt, nem volt se negatív, semmi. Azt mondta, hogy a korábbi problémákra nem volt megfelelő reakció.

Annak nem sok értelme van, hogy azt mondjuk, de igen, de igen.

Én szívesen készítenék kis peccseket a paxból, amik aztán egyenként bekerülhetnének a kernelbe.
Csak az a baj, hogy nem értek a kernelhez, nem értek a paxhoz, és C-ben 13 éve nem programoztam (meg egyébként se nagyon programozok semmit az elmúlt 5 évben)

Szóval szerintem ez lenne a jó irány, lebontani kis darabokra, amik Linusnak megfelelnek.

De nem tudom, ki csinálhatná ezt. A grsec csapat az elmúlt években, gondolom, nem próbálkozott ezzel.
Nem tudom, kinek másnak lenne meg hozzá a tudása.

Ígyhát nem tudom igazán, hogy egy következő levélben mit írnék.

Maximum önkénteseket keresnék.

G

subscribe

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Nem lehet, hogy rossz iranyból közelítünk?

Ha Linux & co. nem hajlandó betenni a kernelbe, ám ne tegye be.
A Debiannak / SuSEnak, meg a többinek picit sem lenne fájdalmas, ha egy make -el többet indítanak...

Csak egy tipp...

linux-image-2.6.18-4-486 - Linux 2.6.18 image on x86
linux-image-2.6.18-4-686 - Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.18-4-686-bigmem - Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.18-4-amd64 - Linux 2.6.18 image on AMD64
linux-image-2.6.18-4-k7 - Linux 2.6.18 image on AMD K7
linux-image-2.6.18-4-vserver-686 - Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.18-4-vserver-k7 - Linux 2.6.18 image on AMD K7
linux-image-2.6.18-4-xen-686 - Linux 2.6.18 image on i686
linux-image-2.6.18-4-xen-vserver-686 - Linux 2.6.18 image on i686
linux-image-2.6.18-5-486 - Linux 2.6.18 image on x86
linux-image-2.6.18-5-686 - Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.18-5-686-bigmem - Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.18-5-amd64 - Linux 2.6.18 image on AMD64
linux-image-2.6.18-5-k7 - Linux 2.6.18 image on AMD K7
linux-image-2.6.18-5-vserver-686 - Linux 2.6.18 image on PPro/Celeron/PII/PIII/P4
linux-image-2.6.18-5-vserver-k7 - Linux 2.6.18 image on AMD K7
linux-image-2.6.18-5-xen-686 - Linux 2.6.18 image on i686
linux-image-2.6.18-5-xen-vserver-686 - Linux 2.6.18 image on i686
linux-image.-2.6.18-5-grSecurity-686 - Made by the , because Linux wants something else

Itt az volt az aktuális propaganda egyesektől, hogy majd akkor indul be a fejlesztése, ha a mainline kernel része lesz. Ha ez az elmélet igaz, akkor a te javaslatod ezen nem segít (az más kérdés, hogy szerintem a mainline beolvasztás sem).

Ha arra vonatkozik a javaslatod, hogy hogyan lehetne népszerűbbé, ismertebbé tenni, akkor azt mondom, hogy ez az út talán.

--
trey @ gépház

Jo, hat erted :)
BSD -zek, csak tudom, hogy a grsec jo dolog, nem lenne szep dolog, ha hagynank veszni, legalabb kinlodni kene erte.

Ha bekerulne a nagyobb disztrokba - mint opcionalis kernel, egyszerubb lenne az eset, vagy, ha a grsec weblapon heepelne az oracle / sap / meg a tobbi anyaszomorito, hogy hu de tenyleg, grsec nelkul mar nem is server a server.

De minden nelkul nehez, akkor mar legalabb a distroba keruljon bele.

Ehhez nem feltétlen kell azonnal disztrótámogatás. Nyitsz egy saját repositaryt akár rpm hez akár deb hez, és csinálsz kis marketinget köré. :-)

Egyébként van már ilyen is. Az RPM félét egy "cormander" nickű / de szép kreált szó :D/ jómunkás csinálta, de van deb repositary is debianhoz ill. uborkához.

A probléma ott van, hogy ha lejár a disztró kernelcsomagjának ;-) szavatossági ideje, akkor egy másik kernelre kell "ráállni", és ha megszűnik a fejlesztés, nem biztos hogy ahhoz a kernelhez amire akkor ráállnak lesz még grsec.

amúgy erre esetleg ha jó ötletnek tartja és tud angolul, valaki bepostolhatna egy paxtest kimenetet vanilla kernellel, és egyet grsec/PaX os kernellel is (pageexec/segmexec+mprotect beállításokkal) persze kísérőszöveggel.

Egy uderef+kernexec "demonstrációhoz" talán a vmsplice() os exploitra lehetne visszakanyarodni.Amennyire emléxem, ott akiknél grsec futott megfogta az exploitot és nem lett "rootshell". :)

info: A paxtestet még P. Brusser csinálta a "néhai Adamantix" fejlesztője.

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

r=1 vagyok, de ugatok...

arch linux 2.6.27-ARCH (vanilla):

Executable anonymous mapping             : Vulnerable
Executable bss                           : Vulnerable
Executable data                          : Vulnerable
Executable heap                          : Vulnerable
Executable stack                         : Vulnerable
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
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)        : 14 bits (guessed)
Heap randomisation test (ET_DYN)         : 14 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 16 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 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            : Vulnerable
Executable shared library data           : Vulnerable
Writable text segments                   : Vulnerable

Az én kísérőszövegem ha tudnék angolul, kb ilyesmi lenne:



Úgy tűnik az eltelt évek dacára, még mindig jócskán el van maradva 
a vanilla kernel a grsecurity vel patchelttől a feature-k terén.
Itt van pl. egy 2.6.27-vanilla kernel , 
és egy 2.6.27 -grsecurity patchelt kernel paxtest-el készült teszteredménye.
A kettő között azért még mindig látható némi különbség. :-)

Ha valaki tud jobbat, legyen az. Tőlem most ennyire telt. :-)

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

r=1 vagyok, de ugatok...

Csak nekem van olyan erzesem, h az lkml-es thread meg az itteniek alapjan a grsec team-nek talan nincs is velemenye, hogy egy fel mondatos hozzaszolast nem olvasunk toluk?

Nem hiszem el, h ennyi ido alatt a kocsmaban ne szolt volna neki(k) valaki, hogy ez a level megjelent a listan, meghozza valasz kisereteben.

Bocs, abszolut nem ismerem a szemelyiseguket, igy nem tudom, mi az 'elvarhato' magatartasuk ebben az esetben.

Off-list levelet váltottam Robert-tel.
Jó lenne, ha Pipacs és Brad is hallatná a hangját a témában.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

igazabol se idom se kedvem nem volt belekeveredni ebbe az egesz diskurzusba, de hadd irjak par keresetlen szot akkor (azt is csak roviden, szoval ne varja senki, hogy az elmult napokban felmerult osszes suletlensegre valaszolni fogok. hiaba, oregszem en is ;).

1. szponzoralas

alapvetoen a dolog ugy mukodik, hogy azon cegektol var(t) spender tamogatast, akik penzben merheto hasznot huznak a grsec-bol, kisemberek egyszeri kis adomanyaira nem lehet hosszutavon alapozni, open source kommuna ide vagy oda (sajat becslese szerint az elmult 8 evben 200 USD alatt volt pl. az itthonrol erkezett tamogatas). amugy nem nagy osszegrol van szo, par ezer USD evente plusz a hosting. mindezzel egyutt elegge elege van az egesz projektbol, se a munkaja se a hobbija nem koti mar a linux-hoz, tehat ez amolyan 'megcsinalom mert meg megeri' alapon megy mar egy ideje, ki tudja, mi lesz hosszu tavon. ez van, semmi sem tart orokke.

2. beolvasztas

ez mar nem tudom, kinek az agyabol pattant ki, de ugy hianyzott nekunk most, mint uveges totnak a hanyatteses.

eloszor is, *mi* soha semmilyen formaban nem kuldtunk be semmit se a pax-bol se a grsec-bol (nem szamolva altalanos bugfixeket persze). es most tessek figyelni nagyon: *SZANDEKOSAN*. mi tobb, korabban mar elmondtuk parszor, hogy miert, lehet keresgelni a forumon meg a levlistan, meg az irc logokban. ebbol persze mindjart kovetkezik, hogy a kernel fejlesztok egyikenek se lehet sok velemenye az altalunk be nem kuldott patch-ekrol, tehat ok mindig masrol beszelnek, amikor azt hiszik, hogy az a pax-rol vagy grsec-rol szol. tipikusan az exec-shield-del szoktak osszekeverni, ez latszik Linus elszolasabol is (pax-ban nincs 'emulate NX bit badly', ott tokeletesen mukodo, per-lap PROT_EXEC van, ketfele modon is mellesleg, ill. amennyire en tudom, 'much of it' soha nem ment be a pax-bol, az exec-shield-bol annal inkabb, mondjuk az is messzire vezet, hogy miert kellett feltalalni a spanyolviaszt).

masodszor, ha mar valaki magara vallalja a fogadatlan prokator szerepet, legalabb annyi intelligenciaja igazan lehetne, hogy egyreszt *eloszor* megkerdez bennunket, hogy megis mit gondolunk minderrol, masreszt, ha mar a fel lkml-nek kepes CC-zni az egeszet, akkor talan a legfobb erintetteket se kene kihagyni. igen trey, ez neked szol, de mondjuk dwokfur-t is megszivattad, aki szegeny hiaba forward-olta a sajatjat, cseberbol vederbe jutottunk csak vele. hiaba vagtok hozzam marc.info-s linkeket, ha egyszer abbol se a msgid, se az eredeti CC lista nem derul ki, lehet faszan valaszolni a nagy semmibe (kb. senki nem kap lkml-t intravenasan, a CC a modja annak, ha valakinek a figyelmet fel akarod kelteni). na nem mintha lett volna sok mondanivalonk, lasd elozo bekezdes.

3. utoszo

igazabol nincs mit, inkabb kivancsian varom, ki mennyit fog megerteni ebbol az iromanybol, ill. lesz kepes levonni a kovetkezteteseket az elozo napok hozzaszolasaira vonatkozoan. kulonosen ha az a sajatjait is erinti (igen, ki lehetett volna osztani jo par balfasz dijat, de most megkimellek benneteket. mondom oregszem ;).

Jan 04 10:19:07 mgabor ez csak egy teszt volt hogy hupon nagy pofajuak kozul ki mer oda ugatni
Jan 04 10:19:10 mgabor de egy sem mert
Jan 04 10:19:26 mgabor lehet ott nyomni a propagandat
Jan 04 10:19:26 Hunger- lejatszott dolog ez, minek ujra vegigmenni rajta
Jan 04 10:19:48 mgabor ha en valamit szeretnek akkor nyomom a dolgot
Jan 04 10:19:54 gabucino don't bullshit the bullshiter
Jan 04 10:20:11 mgabor itt az latszik, hogy a kernelfejlesztok reszerol lenne hajlandosag a jo reszek megtartasara
Jan 04 10:20:21 mgabor a masik oldalrol nincs semmi rugalmassag
Jan 04 10:20:34 Hunger- a masik oldalrol nem lehet mit csinalni
Jan 04 10:20:46 mgabor miert?
Jan 04 10:21:04 Hunger- egy kibaszott bonyolult security megoldasnal, amelyik iszonyat melyen turkal a kernelbe, nem lehet egyszerusiteni es bekuldeni mint patch
Jan 04 10:21:22 mgabor ehhez politikai erzek kell
Jan 04 10:21:28 mgabor be kell kuldeni kisebb reszeket
Jan 04 10:21:31 gabucino dehat akkor nem eletkepes!!!111oneoneeleven
Jan 04 10:21:31 Hunger- olyan dolgokat valtoztat, amit vagy elfogadnak es mindenki ezentul figyelembe veszi vagy nem es akkor nem lehet beolvasztani
Jan 04 10:21:38 mgabor ha az bekerult lehet nyomni mar
Jan 04 10:21:44 mgabor mas is ezt csinalja
Jan 04 10:21:51 Hunger- mondom nem ilyen egyszeru
Jan 04 10:22:05 Hunger- en sokat vitatkoztam mar errol a paxteamel hidd el
Jan 04 10:22:09 gabucino en azt nem ertem a PC speaker drivert miert nem mergeltek anno
Jan 04 10:22:15 gabucino rohadt kocsogok
Jan 04 10:22:27 mgabor nekem az az erzesem, hogy nem is akarjak spender meg paxteam
Jan 04 10:22:38 Hunger- mar nem is, ez valo igaz
Jan 04 10:22:46 mgabor akkor dolgozni kene vele
Jan 04 10:22:56 Hunger- de min es kinek? :)
Jan 04 10:23:06 mgabor megmondtak a flufferek a hupon
Jan 04 10:23:11 mgabor majd akkor fejlesztene mas
Jan 04 10:23:17 Hunger- eleve fel se fogja a sok kernel devel a pax/grsec jelentosegenek 90%-at
Jan 04 10:23:17 mgabor ott szakadtam a rohogestol
Jan 04 10:23:34 Hunger- MS-nel is 6 ev kellett, hogy megertsek es egyes otleteit felhasznaljak
Jan 04 10:23:39 mgabor ezt tudjak szajkozni "ha bekerulne, ha bekerulne"
Jan 04 10:23:46 mgabor kantaljak mint a mormonok
Jan 04 10:23:54 mgabor lehet akkor most ott kantalni
Jan 04 10:23:57 Hunger- en nem szajkoztam, hogy keruljon be imho
Jan 04 10:24:04 mgabor nem azt mondtam hogy te
Jan 04 10:24:11 mgabor hanem az ott okoskodok
Jan 04 10:24:23 mgabor ez a tipikus bikeshed
Jan 04 10:24:30 mgabor fogalmatlan de mondja

PaxTeam-nek köszönet a megerősítésért.

--
trey @ gépház

"A grsecurity, a PaX fejlesztőjének és felhasználóinak egybehangzó véleménye". szerintem ezt benezted, bar hogy magaddal szoljak: "Kíváncsi voltam, hogy meddig bírod egyébként. Abban is biztos voltam, hogy ha nem bírod tovább akkor ez a stílus fog kiütközni a hozzászólásodon. Nem csalódtam."

amugy Linusnak epp most irtam meg maganlevelben, hogy egy blogger trollkodasanak az aldozata lett, kezelje akkent, de gondolom a te kicsinyes agyadnak ez akkor is valamifele 'gyozelem' marad mar ;).

a levelet, ami "csak egy teszt volt hogy hupon nagy pofajuak (akik "ezt tudjak szajkozni ha bekerulne, ha bekerulne") kozul ki mer oda ugatni" veletek "nagypofájú" "mormon" "flufferekkel" beszélte meg szombat dél és este 9 között (ekkorra már válasz is érkezett rá)

van róla valamilyen információd, hogy ezen idő alatt paxteam és spender urak hol voltak a nagyvilágban és éppen mit csináltak? vagy ha valahova ezentúl egy troll blogger bármit beír, akkor arra rövid határidős, pecsétes, hivatalos reakciónak kell érkeznie? a "nem a hatatok mogott irt levelet"-ben ki a "ti"?

> miert nem a level elkuldese elott irtad h "kosz trey nem kell" vagy akarmit?

lehet hihetetlennek hangzik, de az *en* eletem nem a hup.hu nevu trey maganprodukcio korul forog (szemmel lathatoan ezzel sokan nem igy vannak, lelkuk rajta). tehat nem kovetem minden rezduleset, plane nem a nem fohirkent megjeleno irasokat. valo igaz, Hunger kuldozgetett nekem linkeket ide a hetvegen, de egyreszt volt jobb dolgom is (epp utaztam), masreszt nem olvastam el vegig mindent, es igy az se tunt fel, hogy mi keszult itt valojaban (ti. hogy a mi nevunkben is megy a nyilatkozat). nem gondolod, hogy ha trey ugy dont, hogy egy bennunket erinto kerdesben, raadasul a mi nevunkben is ir valamit, akkor a *minimum* az, hogy errol maga ertesit legalabb engem (ha mar angolul nem akar irni)? mert mindez nem tortent meg, csak miutan irt az lkml-re (ujfent CC nelkul!), utana odavagott hozzam egy marc.info-s linkeket tartalmazo levelet. nesze semmi, fogd meg jol? szerinted ez a korrekt eljaras?

> nem a hatatok mogott irt levelet.

pedig pont ez tortent. szoval elarulod miert is probalod meg vedeni a vedhetetlent?

Egyetértek veled, hogy megkérdezhetett volna téged először. Ő biztos tudja az okát... én max találgathatok
pl: lehet azért mert ismerte/sejtette a hozzáállásotokat és úgyis lebeszéltétek volna, hogy nem kell meg nem tudom és seperjük a gondokat a padló alá és akkor nincsenek szem előtt stb.
Ő meg szerette volna esetleg elindítani mégha nem is a legszebb módon -persze nem tudhatju...-

hat szerintem nem olyan nagy baj, hogy elkuldte. Mar amennyiben kerdezni azert szabad es linus korrektul valaszolt is - bar o biztos nem olyan nagy ember mint a valamivel arrogansabb paxteam.
Na mindegy, nem akarok beleszolni a nagyok beszelgetesebe, en sajnos nem vagyok kernel hacker se.

- Use the Source Luke ! -

"A grsecurity, a PaX fejlesztőjének és felhasználóinak egybehangzó véleménye, hogy a megoldás megmentésének egyik lehetséges módja - megfelelő szponzor találásán kívül - a mainline kernelbe olvasztása lenne."
Erre akartam utalni, nem a feladóra. Elnézést a pontatlan fogalmazásért.

Lehet hogy lehetett volna jobban is szebben is -előbb megkérdezni stb-, de senki nem mondott semmit... senki nem tett semmit.

Gábor úgy döntött -szerintem helyesen- hogy nem ül tétlenül s megpróbál tenni valamit. Nem csak ölbe tett kézzel hagy veszni egy többek számára hasznos projectet. Megpróbált elindítani egy párbeszédet... s az idő pedig eldönti, hogy jó vagy rossz irányba megy el.

Szerintem nem egymást kéne szidni és szítani no meg lejáratni... csinálják azt elegen az országban -sajnos-. Már megtörtént és pont. Kérdés, ami fentebb már megválaszoltál, nem érdekel titeket a továbbiak. Innentől felesleges bármi véleményt alkotni, hisz ő abban a reményben próbált _segíteni_, hogy az eddigi munkátok értéke megmaradjon.

Minden esetre szerintem a szándék mindenképp jó volt, mert ügye van úgy hogy dacból nem beszélnek egymással egyesek. Ilyenkor pedig jól tud jönni, ha van aki elindítja a párbeszédet.

Most utólag, pedig már mindenki belátja, hogy úgy tűnik sajnos felesleges volt... de legalább valaki csinált valamit.

Üdv:
Csabka

> de senki nem mondott semmit... senki nem tett semmit.

ezt honnan veszed? talan megkerdeztel engem vagy spendert, hogy hogyan all a dolog?

> hogy nem ül tétlenül s megpróbál tenni valamit.

ja, a sajat szavaival: <mgabor> ez csak egy teszt volt hogy hupon nagy pofajuak kozul ki mer oda ugatni. sut belole a joindulat es segiteni akaras, mi? ;)

> Megpróbált elindítani egy párbeszédet

szerinted hany fel szukseges egy parbeszedhez? mert ha egynel tobb, akkor legy szives magyarazd el, miert nem CC-zett bennunket. nem veletlenul hallgat rola.

> de legalább valaki csinált valamit.

ja, csinalt. mifelenk ezt szarkavarasnak hivjak.

Szerintem is hibázott, hogy nem CC-zett illetve nem kérdezett meg. Gondolom meg volt rá az oka. Nem hiszem hogy csak úgy unalmába irogat Linusnak.

Azt pedig, hogy a " ez csak egy teszt volt hogy hupon nagy pofajuak kozul ki mer oda ugatni" kiragadott mondatot miért mondja, csak ő tudja.

Félre ne értsd nem védem Gábort, de nem is támadom. Lehet hogy nem a legjobb módszer volt, s lehet hogy nem is így kellett volna, de már megtörtént.

Amúgy Te megkérdezted privibe tőle, hogy miért így csinálta, vagy csak a fórumon hordtad le mindenki előtt, hogy miért tette? Nem kell válaszolnod, csak úgy érdekelne...

> Félre ne értsd nem védem Gábort, de nem is támadom.

ja latom. amikor Gaborkad bunkosagat sajat maga igazolja, akkor 'meg volt ra az oka' meg 'o tudja, miert mondja' meg 'mar megtortent'. amikor en megpedzegetem, hogy talan megse ez volt a legintelligensebb elintezesi modja, akkor az meg mindjart lehordas. am legyen, de amit nyilvanosan csinalt, azt vedje meg nyilvanosan. persze ahhoz kene nemi gerinc is, Gaborkad pedig nem eloszor bizonyitotta be, hogy az neki nem sok van.

A sok hőbörgés helyett nem lett volna egyszerűbb sértődés nélkül válaszolni a listán, hogy félreértés van, ti nem is akarjátok beolvasztani a mainline kernelbe a PaX-ot? Ehelyett itt tépitek a szátokat, meg írogattok Linus-nak privát levelet és pocskondiázzátok azt, aki akármilyen indokkal, de felemelte a szavát a projektetekért... Én sem trey-t védem, csak kicsit mintha túlreagálnátok ezt a dolgot...

a megsertodeshez az kellene, hogy trey-nek jelentoseget tulajdonitsak, de mint mar tavaly is irtam valamikor, ilyenje neki nincs. viszont amikor eloadja itt a drama queen-t, hogy o mennyire a sziven viseli a grsec sorsat, meg egyeb hazugsagokat, es bele akar rangatni egy altalam/altalunk egyaltalan nem kivant diskurzusba, akkor nem megyek el mellette szo nelkul. de ha te tovabbra is ugy gondolod, hogy trey barmit is ertunk tett itt (elolvastad te az irc logjat egyaltalan? esetleg kerd el tole meg az utana irt par perc anyagat is), akkor kivanok neked ezerszer ennyi joakarot, remelem jol fog esni ;).

Olvastam, ezért írtam, hogy "bármilyen okból" :)
Több dolog el lett baszarintva szerintem ezzel a grsec/PaX mentőakcióval, az egyeztetés kihagyásától az irc beszóláson át ettől a fórum viharig. Persze eső után köpönyeg az én előző hozzászólásom is, nem is folynék bele jobban. Maga felvetés az irclog-ig egészen normális volt, a cél mindenesetre támogatandó, a motiváció, nos, az tré. Ha valaki segíteni akar nekem, akkor az díjazandó akkor is, ha csak azért teszi, hogy utána röhöghessen rajtam (ha valakit ez boldoggá tesz, hát tegye és segítsen legközelebb is :)

Peace izé Pax :)

kedves trey. mi, fogalmatlan okoskodók, akik a beolvasztás előnyeit próbáltuk összelapátolni, feltételeztük, hogy a fejlesztőknek nem ennyire hatalmas a "lelkesedése". de nem kezdtünk el egyből lkml-re levelezgetni (mellesleg én személy szerint soha nem írtam még oda, és a jövőben sem tervezem, akár egy projekt jövője függ tőle - ami nem valószínű, hogy az én szavamon állna vagy bukna -, akár nem). nekem valamiért úgy tűnik, hogy a levél, amit megfogalmaztál, nem épp meggyőződésből íródott, inkább olyan lets have some fun stílusban, főleg a log fényében. így viszont nem igazán látom értelmét, főleg, hogy nem kérdezed meg azoknak a véleményét, akik nevében írtad. azért szvsz kár volt ezt a kört lefutni, hogy előadhasd az émmegmontam dumád a puszipajtásodnak meg az udvari bolondodnak.

( trey | 2009. január 3., szombat - 18:12 )
Köszi. Ha csak ellenvetés nincs, akkor elküldöm ezt a levelet a címzettekhez.

nem volt, volt? nem volt. es az nem igaz h 1 level ellenzo se jart hup kozelebe abban az idobe

( trey | 2009. január 3., szombat - 12:44 ): Javaslat egy levél elküldésére
nem tudom mien idozonaba van a marc.info vagy a kernel.org, de vegyuk csak LGEE forditasat ami 18:10 kor lett lejegyezve

az 5 ora. nem hiszem h senki nem volt online az ellenzok kozul.

--
1&2

Mondjuk én még mindig nem értem, hogy miért kellett volna a hup-on az ötletet jónak tartóknak, illetve a grsec/pax felhasználóknak az lkml-en Linux válasza után "odaugatni".

Megírtad, hogy úgy gondoljuk, jó lenne beolvasztani. Erre írt Linus egy normális hangú levelet, miszerint ennek ez és ez a módja.

Mit vártál? Hogy mondjuk én, mint nagy pofájú, odamegyek ugatni, hogy de, de, olvasszátok be, mert azt akarom én is?

Nem értem az egészet. Linus válasza előtt esetleg lehetett volna írni, hogy +1, +1, de utána...

G

bar meg nem 100% biztos (de 99% igen ;) es ezert nem akartam meg leirni: minden jel szerint lesz szponzor (igazabol nem is egy, de majd elvalik), tehat egyenlore nagyon ugy tunik, hogy mehet tovabb a projekt. mas kerdes, hogy spender motivacioja mar nem a regi, tehat a hosszutavu fejlesztesre tovabbra is all, amit irtam.

paxteam-nek: ilyen szöveggel valszeg a továbbiakban se fognak tolongani az adakozók. nem az, hogy köszönöm, vagy hasonló, hanem hülyékvagytokmind. zsír. a másik, hogy bármilyen meglepően/sokkolóan fog hatni, a grsec nem csak a ti/a szponzorotok elégedettségére van (úgy tűnik, akaratotok ellenére), hanem sok más ember is használja/használná. és nem lelkesül fel túlságosan, mikor benyögik, hogy hát bocs, lehet megdöglik a dolog, mainline-ról hallani sem akarunk, kuka az egész, ti meg menjetek inkább legózni. szerintem természetes, hogy próbálnak valamit kitalálni a sok munka megmentése érdekében (ha már titeket nem nagyon izgat).

kicsit sokmindent kavartal ossze.

eloszor is pont en vagyok/voltam az, aki egyaltalan nem akarta veszni hagyni az egeszet, se korabban (amikor en kerestem a PaX-hoz karbantartot), se most, amikor spender szo nelkul dobta volna az egeszet (igen, felolem szidhatod emiatt, de elarulom, hogy nem fogja erdekelni) es jo kis rabeszelesembe kerult, mire engedett.

masodszor, nekem nem szokasom belerugni a sajat felhasznaloinkba (nem vagyunk OpenBSD ;), a PaX nem tartana itt, ha nem kaptam volna rengeteg segitseget, visszajelzest, stb az evek soran. ez a szal (meg a kapcsolodo hir is) azonban nem errol szolt, hanem bizonyos trollok maganszamava valt (a joakarok minden szandeka ellenere), errol irtam azt, amit. erre azt szoktak mondani, hogy akinek nem inge, ne vegye magara. nem mellesleg pont neked is volt jonehany ilyen megnyilvanulasod, de szo nelkul hagytam.

harmadszor, tetszik vagy nem, az ember sajat szabadidejeben fejlesztett projektek (mint grsec meg PaX) sorsa az, hogy allando bizonytalansagban vannak. akinek ennel tobbre van szuksege, az nyuljon a zsebebe, azert leteznek cegek meg fizetett termektamogatas. hozzateszem, hogy ezen az sem segit, ha a kod bekerul akarkinek (Linus/distro/stb) a fajaba, ha ugyanis nincs karbantarto hozza, akkor nem lesz sokaig ott (ill. tobbek kozott emiatt eleve be sem kerul). ilyen meretu es bonyolultsagu kodnal, mint a mienk kizart dolog, hogy nem foallasu karbantarto nelkul elfogadjak a kodot (nem beszelve az egyeb okokrol, amik miatt nem kuldjuk be). ha esetleg nem tunt volna fel, a linuxot kb. 15 eve mar szinte kizarolag foallasu (es eleg jol fizetett) programozok fejlesztik, az amatoroknek a nehany soros javitasok jutnak.

Engem érdekelnének az indokok, ha valaki megtalálta a fórumokon, levlistákon, irc logokban, írjon legyen kedves egy URL-t, köszi!

Magánvélemény (úgy, hogy nem ismerem a be nem olvasztás indokait): ha ki akar szállni a fejlesztő a fejlesztésből, akkor lenne igazán jó betolni a vanilla kernelbe a cuccot, így ha ő mondjuk veszi a kalapját, akkor is még a következő kiadásnál, meg az utáni kiadásnál fog még működni a cucc azoknak, akik használni szeretnék.
Persze ha nincs valami elhivatott karbantartója, akkor lehet, hogy idővel valami átstrukturálás miatt már nem fog működni (vagy nem az egész), de mégis... feltételezem, ez még odább van.

Egyébként egy ilyen dologban, mint Grsec meg Pax, mit kell fejleszteni folyamatosan?

Egyszer megcsinálja a fejlesztő, ez OK.
Új kernelekhez illeszti, ez OK.
Hibákat javít, ez OK.
Továbbfejleszti... ezt nem tudom felmérni. Sok új feature került bele az utóbbi időben? Vannak további kifejlesztésre váró ötletek még a jövőre?

Mondjuk azon a részen viszont elgondolkoztam, hogy ha vannak cégek, amik pénzben mérhető hasznot húznak a termékből, és ezért fizetnek valamit, akkor hogy van az, hogy a válság miatt most már nem fizetnek?
Csődbe ment a cég?
Vagy úgy gondolja, hogy nem fizet, legfeljebb a következő kernel verzióval már nem fog grsec-et használni (és így elesik a pénzben mérhető haszontól)?

G

A grsecurity weboldalán található
href="http://www.grsecurity.net/lsm.php">leírás meglehetősen kevés technikai okot sorol fel, miért tartja Spengler az LSM-et alkalmatlannak arra, hogy arra portálja a grsec-et és az így bekerüljön a mainline kernelbe. Az
href="http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm">RSBAC oldalán messze jobban összefoglalják az okokat.

Emlékeim szerint ez már nem az első alkalom, hogy a grsecurity eltűnése szponzor híján fölmerült. PaXTeam itteni jelzései alapján sajnos azt kell mondjam, hogy az új szponzori szerződés lejártával (egy év múlva?) ugyan itt tarthatunk, mint most. Részemről alaposan át kell, hogy értékeljem az eddigi véleményemet a grsec-ről, jövőjéről, és hogy mennyiben lehet, szabad rá támaszkodni :-((.

Csupán két kérdés nem hagy nyugodni: a grsecurity, RSBAC, LIDS, stb. fejlesztői miért nem álltak össze az elmúlt évek során, és miért nem írtak egy LSM2-t, amivel kiküszöbölnék az LSM hiányosságait? Rögtön egészen más színe lenne a dolognak és lenne egy alap, amire portálva a rendszereiket egységes kereten keresztül léphetnének előrébb.

A másik a PaX: vajon az miért nem kerül be a mainline kernelbe? Ott melyek a (technikai) okok, amelyek lehetetlenné teszik azt?

Már korábban elolvastam, de PaXTeam szerint Linus nem is a PaX-ról alkotott véleményt, mivel azt sosem küldték be.

Miért is?

Az, hogy a válaszért "lehet keresgélni fórumokon, levlistán meg IRC logokban", nem igazán segítőkész magyarázat: a grsec fórumaiban pl. a "PaX kernel inclusion" szavakra érdemi találat nem volt; a grsec levlista nem kereshető, a MARC-on archiválva nincsen; az IRC logokat meg ugyan hol keressem?

Arra gondoltam, hogy az egész i386-ot a szegmentációval együtt hülyeségnek tartja Linus a trey postjára küldött válaszában, pedig ez a PaX egyik alapeleme. Innentől nincs értelme tovább gondolkodni a beolvasztáson. Pláne, hogy Linus nincs is képben. Nem is érdeklik az ilyen dolgok.
Nem volt akkor időm jobban kifejteni - utólagos elnézést kérek.

Amúgy respect. Ipset mikor lesz a mainline-ban?

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

itt irtam altalanossagban (elvileg matol barki olvashatja), ha van konkret kerdes, akkor itt is vagy ott is lehet kerdezni nyugodtan.

az LSM-rol annyit mondanek, hogy az egy erosen politikailag motivalt folyamat eredmenye volt, alapveto donteseknek nem volt koze technikai megfontolasokhoz (pl. authoritative vs. permissive hook-ok kerdese, vagy minek hivtak oket). kispalyas jatekosok eleve ki voltak hagyva az egeszbol, teljesen celtalan lett volna beleszolni a folyamatba, sokkal nagyon jatekosoknak sem sikerult elerni, amire szukseguk lett volna (pl. hany eve nem kerult be a CoDomain->SubDomain->AppArmor evoluciot bejaro kod?). irni egy masik LSM-t meg... minek? grsec-nek is meg RSBAC-nak is megvoltak a sajat hook-jaik, mi ertelme lett volna valami kozos nevezot talalni (mar ha egyaltalan lehetseges)? folosleges idobefektetes (utalnek az lwn-es valaszomra meg a szabadido hianyara), senki az eletben nem akarta oket egyutt hasznalni, mert ertelmetlen (mint ahogy ket LSM-et is az).

PaX-szal kapcsolatban meg egyszeru a dolog: Linus valamiert ki nem allhatja az i386 szegmentaciot, es minden erre epulo dolgot mereven ellenez (l. Exec-Shield visszautasitasa). a PaX kb. osszes kernel onvedelmi mechanizmusa erosen szegmentaciora alapul, tehat ezek eleve buktak. aztan ott van pl. a vma tukrozes, ami egy nem trivialis VM alrendszer modositas es ehhez kepest eleg kicsi a haszna (marmint manapsag, anno, amikor az NX bites i386 procik nem leteztek, persze mas volt a helyzet, pont ezert letezik PaX ugye :). marpedig Linus masik elve, hogy o csak olyan kodot vesz be, ami kb. 'orokke' hasznos marad. eleg csacsi felfogas, dehat az o fajat o kezeli. aztan van meg jo par kisebb-nagyobb modositas, ami nem konfiguralhato de szukseges bizonyos feature-okhoz, pl. en a per-cpu GDT-ket visszaraktam egy nagy tombbe, mert igy lehet a legjobban megvedeni oket. ez megint olyan dolog, amit Linus soha nem fogadna el, marpedig akkor tovabbra is nekem kene karbantartani, a tobbi erre epulo feature-rel egyetemben - akkor meg minek torjem magam mas reszek beolvasztasaval, ha eredoben nem lesz lenyegesen kevesebb a PaX-ra forditando idom.

Mivel az LSM már ott van, irreális, hogy azon felül egymástól függetlenül a grsec és RSBAC is (vagy csak az egyik, de a másik viszont már nem) bekerüljön a kernelbe. Ezért gondolom minden fél által kezelhető megoldásnak egy LSM2 kialakítását. Még érdekesebb lenne, ha az pl. felülről legalább részben kompatibilis tudna lenni az LSM-el. Nem azt mondom, hogy egyidőben több LSM2 alrendszert lehessen aktiválni, hanem hogy egy közös alapra építkezzenek. Világos, hogy egyáltalán nem kis munka. De ha az elejétől nem politikai, hanem érdemi technikai feladatként látnak neki a hozzáértők (érintettek), akkor egy jó, érdekes és hasznos kihívás lenne.

A PaX-nál pedig annak részletes leírása, hogy melyek a főbb sarok elemei, amire az egész fölfűződik (és biztonságtechnikai szempontból miért pont azok a megoldásmódok lettek kiválasztva) már segíthetne. Úgy értem technikai leírása, nem egy ehhez hasonló fórum-hozzászólásra való (kényszerűen) rövid válaszként ;-). (Az valóban nem úgy megy, hogy Linus meg a többiek majd egy patch-ből hámozzák ki az összefüggéseket.) Nem tartom meggyőzhetetlennek, még akkor sem, ha valamiről egyszer már kifejtette a sarkos véleményét - főleg, ha azt ténylegesen nem is a PaX-ról tehette.

De Te tudod, mi vesz el többet a szabadidődből: folytatni a PaX fejlesztését és folyamatos portálását az új kernel változatokra, vagy valamennyi (még vállalható) kompromisszum árán bevinni a kernelbe. A kibicnek könnyű...

Kár, hogy az LSM bemutatkozása előtt nem került sor érdemi együttműködésre. Így utólag már nehezebb lesz. Kell egy koordinátor és minden projekt részéről idő és energia.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az utolsó sorban a "nem lesz lényegesen kevesebb" az nem véletlenül "nem lesz lényegesen több" akart lenni?

Linus mondjuk azelőtt tért át powerpc-re, mielőtt az Apple Intel-re váltott. Kíváncsi vagyok most mit használ...
Én legalábbis Pentium M-es laptopot és Athlon MP servert használok. Egyikben sincs NX bit...

Spender tényleg nem használja a saját megoldását? Jó lenne azért, ha megtalálná még a fejlesztésben az örömét valahogy.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

> Az utolsó sorban a "nem lesz lényegesen kevesebb" az nem véletlenül "nem lesz lényegesen több" akart lenni?

nem. a 'forditando ido' ugyanis terhet jelent, nem oromot, tehat minimalizalni szeretnem, nem maximalizalni. mas kerdes az uj fejlesztes, arra nyilvan jo lenne, ha tobb ido jutna, de sokfele ok miatt arra nincs sok esely.

Éppen akartam linkelni ezt a cikket, hogy milyen jól leírtad az indokokat a hozzászólásodban.

Kár, hogy sokszor itt az oldalon személyeskedésbe torkollik a beszélgetés.

Én arra lennék kiváncsi, hogy:
- te szeretnél-e full time, megfelelő fizetésért PaX-on / grsecurityn / hasonlóan hasznos biztonsági rendszereken dolgozni
- ebben a felállásban lenne-e kedved azon (is) munkálkodni, hogy az általad írt rendszerek széles tömegekhez jussanak el? Ennek egyik módja a mainline beolvasztás, másik a disztribúciókba való bekerülés.
- ha ehhez a kevésbé érdekes munkához nincs kedved, elfogadhatónak találnád-e azt, ha a szakmai irányításod mellett ezt mások tennék meg?
- hajlandó lennél-e feladni az anonimitásod, vagy pl. megfelelő licenc/fizetési konstrukció mellett átruházni a copyrightod egy non-profit (vagy akár for-profit) szervezetre?

Ha ezekre a kérdésekre nagyrészt igen a válasz, akkor viszonylag könnyen ki lehet számolni, hogy mekkora költsége lenne ennek, illetve milyen üzleti tervek jöhetnek számításba.

Szerintem megnyugtató lenne a Linux fejlődésének szempontjából, ha a biztonsággal kapcsolatos megfontolások nagyobb szerephez jutnának a fejlesztésben.

Sokszor aggodalommal tölt el az a tudat, hogy hány millió kódsornyi szoftver fut akár egy telefonon, akár egy desktop gépen. És a szoftverek íróinak jelentős része nem a biztonságot helyezte előtérbe.

Jó lenne, ha ez pozitív irányba változna záros határidőn belül.

Üdv,
Gergely

a disztribúciókba való bekerülés.

Anno a néhai Adamantix ba bekerült, meg bent van a hardened gentoo - hogy aztán ez mennyire él vagy haldoklik ? - ban is asszem.

Red hat be nyílván soha nem kerül be az exec shield miatt.

hardening Debian inkább csak útmutató, még ez is haldokolni látszik. Az ubuntuba a felhasználói bázis miatt valszeg szintén nemnagyon valószínű a bekerülés.

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

r=1 vagyok, de ugatok...

Az első lépés, hogy opcionális kernelként (szerver és desktop változatban is) bekerüljön valamelyik jelentős disztribúcióba, ami jól integrálódik a rendszerrel. A programok működnek vele, de számokkal bemutatható, hogy a különböző sebezhetőségek X % -át megfogja, amit az alap kernel nem. Amennyiben ezek a számok meggyőzőek, egyre többen fogják használni, majd pedig követelni, hogy az legyen a default. Szerintem ez egy fél éves kiadású disztrónál 3 - 4 release-t venne legalább igénybe, tehát minimum két éves munkával kell tervezni.

Persze lehet, hogy alulbecslem a munkát.

Üdv,
Gergely

A Hardened Gentoo-hoz elérhetők a megfelelő szoftver eszközök a használatára.
http://www.gentoo.org/proj/en/hardened/

Kellemes meglepetésként olvastam, hogy az Ubuntu fordító rendszerébe is kerültek be olyan toolchain-t érintő fejlesztések, amelyek a tetszés szerinti PIE és/vagy SSP fordítást hivatottak kezelni.
https://wiki.ubuntu.com/HardenedUbuntu/Doc

Debian kicsit később kapcsolt:
http://wiki.debian.org/Hardening

Másik vonatkozó HUP thread:
http://hup.hu/node/58324

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

bocsi a megkesett valaszert, de gondoltam, hogy a kerdeseid megernek meg egy miset ;).

szoval a lenyeg az lenne, hogy a kerdesek jok, csak alapvetoen 4-5-6 evvel megkesettek. akkor ui. meg lett volna ertelme minderrol beszelni, akar uzleti szemszogbol nezve is, mara viszont mindez kisse megkopott, a vilag alkalmazkodott (atvette a PaX uzleti szempontbol vallalhato reszeit). kispalyas jatekosoknak, mint nekem, alapvetoen nem sok lehetoseg maradt - legalabbis az akkori technologiat figyelembe veve. mas kerdes, hogy a projekt messze nem futotta ki meg magat, az uj fejlesztesek (a.k.a. todo list ;) meg sok lehetoseget hordoznak, viszont ezek finanszirozasara kb. annyi eselyt latok, mint a projekt eddigi reszere, azaz semmit. az a nagy helyzet, hogy a vilag kb. mindent ingyen akar, kulonosen egy olyan nehezen karakterizalhato szektorban, mint a biztonsag.