grsecurity 2.1.11 - 2.4.36.2/2.6.24.4-es kernelekhez

Hosszú idő után megjelent a grsec patch újabb verziója a 2.4-es illetve 2.6-os kernelekhez. Többek közt az alábbi változtatások történtek:

  • Many bugfixes, including fixes for RBAC auditing and RBAC policy recreation from renaming.
  • Relaxed restrictions for the 'd' subject flag in the RBAC system -- a task may now access its own/proc/-pid-/fd and mem entries.
  • Forced compiler errors on mistaken PaX configuration (such as enabling PAX_NOEXEC but not enabling SEGMEXEC nor PAGEEXEC).
  • Extended username limits in the RBAC system
  • Improved policy verification and base policy enforcement
  • Added support for new capabilities added in Linux 2.6
  • Updated default policy and learning configuration
  • Corrected policy support on files larger than 2gb prior to the RBAC system being enabled
  • An update to the latest version of PaX which includes numerous bugfixes

A bejelentés és további info itt olvasható.

Hozzászólások

Na vegre, erre vartam! :)
Mai programom ugy nez ki meglesz.

A PAX Team valoban befejezi? Nagyon sajnalnam, mert ez az egyik fo oka, hogy grsec patch-et hasznalok. Nem nagyon van helyette mas a "piacon", ami nekem tetszene :(


It is not clear if the PaX Team will be able to continue supporting 
future versions of the 2.6 kernels, given their rapid rate of release 
and the incredible amount of work that goes into porting such a 
low-level enhancement to the kernel (especially now in view of the 
reworking of the i386/x86-64 trees). It may be necessary that grsecurity 
instead track the Ubuntu LTS kernel so that users can have a stable 
kernel with up-to-date security fixes. I will update this page when a 
final decision has been reached.

In the meantime, please email pageexec@freemail.hu and let him know how 
much you appreciate the hard work he has put in for the past 8 years. 
The accomplishments of the PaX Team have extended far beyond just Linux, 
and have today found their way into all mainstream operating systems.

Ciao:
Fonya

Hát én nagyon remélem, és bízom abban, hogy a folytatás mellett dönt.

Ha a kernel jelenlegi (el?)fejlesztési módja miatt valamilyen külső segítség / tesztelés xyz körülmények között, listában szereplő "kernel"függvények/eljárások,/stb-k kódjában volt-e változás, stb. / kellene a folytatáshoz, vagy pénz kéne / itt (is?) volt már valamilyen gyűjtésre irányuló kísérlet / valamilyen munkamegosztásos mókában nekem meggyőződésem, hogy lehetne megoldást találni.

Ha emiatt naív idióta vagyok, akkor azt vállalom, és trey átírhatja a nikkemet. :-)

please email let him know how
much you appreciate the hard work he has put in for the past 8 years.

ha csekélyke angoltudásom szerint / de feltétlen javítsatok ki, mert az angol (sem) nem erősségem / ez tényleg azt jelenti hogy küldjünk támogató emaileket melyben elismerjük az elmúlt 8 évben végzett munkáját, akkor szvsz az emilesládája picit lehet megtelik az elkövetkező pár napban.

---------

Nem a zsömle kicsi, a pofátok nagy...

>> Szóval hogy az újraírások miatt ne kelljen vele neki szívnia

gkh-nak úgyis van elfekvőben 30-300000 saját fejlesztője, akik most éppen gombfociznak, mert nincs cég, aki rájuk bízná akár a drivere manuálját is, őket ki lehetne képezni egy hétvégi szeminárium keretében biztonságot programozni

Tudod bár ne csak ez a néhány bejegyzés szólna a PaX (akár) pénzbeli támogatásáról itt a HUP-on! De mondjuk nem árt ha meg vagyunk győződve arról hogy jó helyre folyna a pénz (a cucc működik, és a fejlesztőnek kell a támogatás). Úgyhogy ha terelném akkor a nagyobb reklámérték irányába.

Én miért írnék? Én nem használok PaX-ot. Ennek ellenére azt hiszem, hogy már azzal támogatom, hogy egy, a célközönség által nagy mértékben olvasott oldalon (HUP) rendszeresen teret adok a témának. Vegyük úgy, hogy a HUP a médiatámogató. Mondom, úgy, hogy én nem is használom. Most jössz te.

--
trey @ gépház