A Grsecurity felfüggeszti a stable patchek publikus terjesztését

 ( trey | 2015. augusztus 27., csütörtök - 10:23 )

A Grsecurity projekt tegnap bejelentette, hogy a beágyazott Linux iparág hozzáállása, ezen iparág egyes szereplői által okozott frusztráltság, a folyamatban levő GPL- és védjegysértések stb. miatt úgy döntött, hogy tegnaptól számított két hét múlva felfüggeszti a stable patchkészletei publikus terjesztését. Azokat az említett dátumtól kezdve csak szponzorai számára teszi elérhetővé. A bejelentés - hogy ne hasson ki negatívan a Gentoo Hardened és Arch Linux közösségekre - nem érinti a tesztelésre szánt test patch sorozatot.

Részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Lehet tudni valamilyen forrásból, hogy melyik volt az a cég, amelyik kihúzta a gyufát?

Tipp:

Wind River

--
trey @ gépház

Jó tippnek tűnik, köszi!

Ez egy 2013as topic. nem hiszem, hogy ennek köze lenne hozzá.
Mondjuk lehet jó lenne, ha ezt inkább spender válaszolná meg találgatások helyett (már ha publikus az információ, vagy annak egy része)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

> one of their employees registering on our forums

"I am a software engineer from Wind River (subsidiary of Intel)"

> and asking for free help with backporting an EFI fix

"Recently, we found this patch will break our kernel's capability to boot from EFI shell."

> to their modified version of grsecurity based off a very old patch of ours

"we ported GRsecurity patch (GRSecurity 2.9.1 -- 201207080925)"

> Mondjuk lehet jó lenne, ha ezt inkább spender válaszolná meg találgatások helyett

Majd engedélyt kérünk valami nagy embertől, hogy beszélgessünk, tippelhessünk a témában.

> (már ha publikus az információ, vagy annak egy része)"

"Since our lawyer has advised us not to mention the companies by name,"

(ugye nem olvastad el a linkelt szöveget?)

--
trey @ gépház

Elolvastam, de tartom magam ahhoz, hogy 2013as cucc nekem réginek tűnik ahhoz, hogy eltörjön a mécses.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Mas forras is Intel-re (WindRiver tulajdonosa) es Verifone-ra mutogat. Es ahogy a cikk is irja, a hercehurca mar tart egy ideje, nem ujkeletu a problema, igy a 2013-as cikk teljesen relevans. Jogi korokben ket ev rovid ido :P

--
|8]

Ez nem GPL sértés?

Miért lenne? A GPL semmit nem mond arról, hogy kötelező mindent nagy nyilvánosság számára elérhetővé tenni. Mint ahogy te is nyugodtan meghegesztheted magadnak otthon, és nem kell kirakni (vagy, hogy ne legyen hülye a példa, mint ahogy a google is saját magának tartott karban kernelt belső használatra, és sose adta ki).

Amit mond, az az, hogy ha valakinek adsz gples progit, ott kell legyen a forrás. Ők bináris kernelt sose adtak tudtommal, csak kernel patchet, azt meg nem kötelező nyilvánosságra hozni, ha ők csak a szponzoraiknak akarják odaadni, have fun. (A bináris kernelt sem kellene egyébként, csak ha adják, kell mellé a forrást is mellékelni. Még a patchet sem kéne jó eséllyel, lásd redhat, egy nagy targéza a módosított srcvel jó.) Azt persze nem tilthatják meg a szponzoraiknak, hogy ezeket tovább terjesszék, ha akarják, hiszen gpl, de a ha akarják hangsúlyos, és van tippem, hogy nem akarják :)

Ha a patch bekerül egy szponzor rendszerébe, amit nem ő használ, hanem értékesít. Akkor az akinek értékesítette a GPL miatt kérheti a forráskódját.

Úgy kérdezem, hogy nem használok grsecurity-t, szóval nézzétek el nekem, ha hülyeség:

ha jól értem, a stabil, nem nagyon változó kernelekre nem lesz elérhető ezentúl, csak valami bleeding edge verzióra, ráadásul az a grsecurity változat is jobban teszt, próbálkozások ez-az is van benne.

Akkor ez azt jelenti, hogy ha mondjuk én 1 hónap múlva úgy döntenék, hogy az otthoni akármi disztribúciót futtató gépemre jó lenne grsecurity, akkor nem lesz elérhető verzió?
Kivéve, ha a disztribúció grsecurity szponzor, és valami módon ők maguk adnak olyan kernelt, amiben már benne van vagy egyszerűen beletehető.

Ha mondjuk Linuxot építenék disztribúció nélkül forrásból kézzel magamnak, akkor annyi lehetőségem lenne a jövőben, hogy a változékony kernel verziót használom a testing grsecurity verzióval?

Szerintem bármikot jelentkezhetsz támogatónak! :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Akkor ez azt jelenti, hogy ha mondjuk én 1 hónap múlva úgy döntenék, hogy az otthoni akármi disztribúciót futtató gépemre jó lenne grsecurity, akkor nem lesz elérhető verzió?

Én kb. 2002 (?) óta használok grsec-et.

Ha stabilabb, megbízhatóbb kernelre akartál grsec-et, régen is úgy ment, hogy egy kinéztél egy kernelverziót (praktikusan egy longterm fára) az utolsó public. grsec test verziót feltetted, lepróbáltad, működött, aztán a vanilla/distro kernel módosításait nyomtad fel a kész grsec-es kernelforrásra.

Ritkán fordult elő, hogy problémák voltak, ha voltak is , általában kezelhető volt a dolog.

A longterm kernel pont azért jó, mert nem basztatják annyira, mint a vanillát, nem kezdenek rendmániás őrültek függvényátnevezésekbe, kódtisztításokba általáluk deprecated-nek vélt részeket illetően. Amik miatt a külső kernelpatchek alkalmazása finoman szólva is körülményes.

Egyszerű ember számára a változások a longtermben könnyebben követhetőek..

A módszer hátránya, hogy a grsec verzió kötött, tehát azt nem fogod emelni. Pl. jelenleg 3.14.y-ra van 3.1.-es grsec, ha kiadnak egy 3.2-est az újdonságok már kimaradnak. Illetve ha átállnak a fejlesztők másik kernelre, akkor neked marad az uccsó teszt verzió kiindulási alapként a választott longterm kernelhez.

A módszer másik mellékhatása / hogy előny vagy hátrány ezt nehéz eldönteni / ritkábban akad majd össze a grsec a distro kernelek longterm fáival. (pl. debian)

A grsec stabil fába ugyanis nem csak grsec ficsőrök, hanem normál kernel hibajavítások is bekerülnek a jelenlegi rendszerben.

Ugyanezen hibákat a distrok is javítják / pár nap, vagy pár hét késéssel ;-) / a saját kernelükben.
De a két javítási módszer időnként jelentősebb mértékben eltér, ami miatt vagy distro kernel, vagy grsec stabil fa volt a választás a jelenlegi rendszerben.

Ezeket a duplikációkat most könnyebb lesz elkerülni.
A grsec teszt verziókba ezeket a gyorsjavításokat ezentúl nyilván nem teszik bele, ha pl. 3 hét múlva úgyis kernel verziót emelnek.

Nem fognak ezzel vesződni, régen is csak rendkívüli esetben tették.

ráadásul az a grsecurity változat is jobban teszt, próbálkozások ez-az is van benne.

Otthoni használatra a ficsőrök amiket használni fogsz, vagy használnál, azért nem tegnap kerültek a grsec-be. ;-)

Maradjunk annyiban, hogy ezek a grsec test verziók azért nem annyira félelmetesek.
A test valójában inkább szól az új kernel verziónak, mint a grsec-nek. ;-))

off: Az egyik kedvencem még a régi időkből az, mikor valamelyik grsec verzióban az UDEREF és az intel dri összeakadt / az intel dri-t akkor éppen nem tudom hányadszorra írták újra exa/uxa -val volt valami cirkusz /,
korábbi verzióval jó volt. De az adott kernelverzióval nem indult az X, ha az uderef ment.

Aztán jött még ki jónéhány intel dri javítás a kernelbe, közte volt null.deref-es is ;-)), aztán egyszercsak megint jó lett. És ezek úgynevezett "stable" kernelek voltak.

Szóval a test nem feltétlen a grsec-nek szól. ;-)

A virtualizáció kérdése az már komolyabb, ott esetleg lehetnek hiányzó funkciók, bár egy ideje már benne van az is. kvm-el szvsz nem lesz gond. virtualbox, vmware már neccesebb lehet, fene tudja.

---------

Én nem lennék meglepve, ha megint lennének a neten barkácsverziók, barkácsbackportok egy idő után grsec-re, mint pl. ez volt annak idején, amikor nem volt stable grsec forrásfa:

http://kernelsec.cr0.org/.

Én valószínűleg ezt az utat választom majd a bttv , lirc miatt amúgy is backportolnom kell saját használatra.

-----------

Én a 3.14-y-t a jessie ciklusa végéig használom a longterm fa változásait pakolgatom be a mostani forrásfába, talán nem lesznek olyan horderejű változások - ált. nem szoktak longterm fában - ami miatt összeakad a grsec-el.
Nekem szerintem jó lesz. régen is kb. így ment.

Közbe begyűjtögetem a test verziókat, ha lesz changelog azokat is, aztán vagy visszaáll a stable support egy idő után - van bő 1,5 év ;-)) jessie végéig - vagy valaki elunja és kernelsec.* módjára lesz barkácsbackport,
vagy ha egyik sem, megnézem jessie után milyen longterm fa lesz, aztán elkezdem azt követni virtuális gépben, mire a jessie lejár, addigra legyen kész utódlás.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Köszi

Vagy fogod magadat, és leszeded a latest stable hardened-sources package forrását Gentoo-éktól. Nekem mondjuk Gentoo-m van, szóval triviális ez a megoldás, de más is megteheti.

Fene tudja, most ebbe belenéztem futólag, átlapoztam nagy vonalakban mibe nyúlnak bele:

http://dev.gentoo.org/~blueness/hardened-sources/hardened-patches/hardened-patches-3.14.49-1.extras.tar.bz2

Tjképpen nem sok vizet zavar, azonkívül hogy eltüntet, ill. beállít pár grsec opciót automatán / hülyeség elleni védelemnek tűnik 90%-ban / amit kernel configurációnál amúgy is meg lehet tenni, meg kivesz fordításnál pár warningot; gyakorlatilag egy az egyben vanilla kernel+grsecnek tűnik.

/Egyetlen kivétel a selinux & grsec kombó esetén a AVC logba berakja a forrás ipcímet is. /

Ha a gentoo hardened folytatja 3.14-es fa supportját, akkor problema gyakorlatilag megoldva, tulajdonképpen elvégzik a grsec backportot.

Ha viszont átállnak 4-esre akkor az nekem debianra nem az igazi...
Abszolút nem ismerem a gentoot, mi a szokás arrafelé ? Mennek a vanilla kernellel , vagy tartanak fent longterm supportot is hardened szálban ?

/ tudom google, de lusta vagyok, ez a mentségem :-) /

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Nálam 3.18.9 van már tavasz óta, és én menni is szoktam kis ráhagyással. 4.0 és 4.1 is van már stable-ben, szerintem valamikor az év végén az egyik fel fog kúszni - azt mondjuk nem értem, hogy a Debiannak ezzel mi baja lenne. Van olyan gépem, amin 2011-es Gentoo fordítás az OS (pár kézzel felrakott program kivételével minden akkori állapotban van), és azon is gyönyörű szépen megy a 3.18.9.

https://packages.gentoo.org/package/sys-kernel/hardened-sources

Innen láthatod, hogy mik azok a régebbi kernelverziók, amiket még tartanak - ezekhez nyilván jönnek ki patchek. Amúgy az a tapasztalatom, hogy vannak kiemelt (LTS-szerű) verziók, amiket megtartanak a régiek közül, míg a többi verzión idővel túllépnek, mostanra pl. a 3.17 meg a 3.18 már lefutott, már csak a 4.0 meg a 4.1 van az újabbakból.

azt mondjuk nem értem, hogy a Debiannak ezzel mi baja lenne.

A debian bináris a gentoo viszont forrás alapú distro. A debianban a binárisok közül is alapvetően régebbi cuccok vannak. Viszont a megbízhatóságuk nagyobb, ami számomra fontosabb, minthogy mindenféle 0day ficsőrökkel legyenek tele.

Sajnos könnyen fennáll a veszélye, hogy a mainline kernelben valamilyen fajsúlyos generál részt deprecatednek minősítenek - sajnos volt már ilyen, nem is egyszer. -, és az erre épülő régebbi bináris cuccok mind egy szálig elzanyá'nak az új kernelen.

A gentoo forrás alapú distro révén ehhez könnyebben alkalmazkodik, a debiannál ez már problémás.

És ilyenkor még google sem tud segíteni, mert ez nagyon speciális eset, amivel valószínüleg más nem is találkozott korábban.
És ez esetben a folyamatosan frissülő kernelhasználati stratégia azonnal bukik.

A debian jelenlegi verzióját nem 2-3 hétig, fél évig , hanem legalább 1, de inkább 1,5 évig biztosan használom 2(+1) hw konfiguráción. És ez minimum becslés, ennél ált. több szokott lenni. :-)

Azt, hogy a mainline kernelben milyen fajsúlyos változások lesznek mondjuk 10 hónap múlva, azt még az se tudja, aki írja. :-))

Pár külső csomagot (pl. mplayer, vice, firefox/iceweasel stb.) lehet utánfordígatni, újat feltenni - mert nem bolygatják meg a rendszer egészét - de pl. a kernellel, glibc-el, kdebase-el célszerű a debian kiadási verzió közelében maradni, hogy ne legyenek hónapok múlva súlyos kompatibilitási problémák.

És amíg a debian jessie a felh. igényeknek megfelel, használt hw-ket támogatja, addig itt a debian marad a kiindulási pont, és minden más ehhez igazodik.
Ezért én backportolásra rendezkedek be. Az a biztos.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Nézd, ez valóban probléma, ha valaki 2015-ben még mindig 2.6.32-es kernelt akar használni, ezt aláírom.
Node nekem az a véleményem, hogy egy 2-3 éves kernel (pl. 3.2) azért már legyen elég régi.

Node nekem az a véleményem, hogy egy 2-3 éves kernel (pl. 3.2) azért már legyen elég régi.

Hát én a debian vizessel 3.2-est használtam pl. a mostani frissítésig. Abban alapból ez van, ehhez időben igazodó/passzoló bináris cuccokkal.

És még mindig nem elavult, mert jessie megjelenés+1 évig szokták sec. frissítésekkel ellátni az előző ún. oldstable verziót.
Úgyhogy hiába akárhány éves, van rá support, szóval nem elég régi.

gentoo szemmel persze lehet, debian szemmel nem. :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

update: Nos eljött az igazság pillanata. Megjelent a 3.14.52-es kernel. A stable grsec patch ahogyan ígérték publikusan nem áll rendelkezésre. hardened gentoo ban ma még 3.14.51 van, úgyhogy nekiálltam a barkácsbackportnak. szerintem nem viszik tovább a szálat.

Úgy ment mint régen, 3,14,52+grsec backport+helyi apróságok (bttv patch lirc backporthoz, stb.) le is fordult, fent is van, egy javítással akadt össze / amit a grsec tartalmazott korábban, de a kernelbe is most már bekerült/, nagyon könnyen kezelhető eset kategóriába tartozott. hamar meg is volt.

Ha van újdonság a grsec patchben az nyilván mostantól kimarad, de hát ez van és kész.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

A szponzorok ügyfelei is kérhetik a forráskódot ha szoftvert és nem szolgáltatást vesznek igénybe, ami használja az érintett kódokat.