|
Message-ID: <20120430161916.GA7042@albatros> Date: Mon, 30 Apr 2012 20:19:16 +0400 From: Vasily Kulikov <segoon@...nwall.com> To: owl-dev@...ts.openwall.com Cc: Petr Matousek <pmatouse@...hat.com>, Eugene Teo <eugeneteo@...il.com> Subject: [GSoC] featues to port Solar, Eugene, Petr - This is a list of security enhancements/features which I think worth porting to RHEL6/OpenVZ kernel. The list is a part of list from: http://openwall.info/wiki/Owl/kernel-hardening Status is one of the following: OK - merged into upstream kernel. DISCUSS - was (is) discussed at LKML, but no explicit ACK/NACK was got. ACK - the idea was ACK'ed, but patches are not merged yet. NACK - the idea was explicitly NACK'ed. nothing - either it was not discussed at LKML or no feedback was received. BINFMT_ELF_AOUT (cleanup) - nothing HARDEN_STACK - nothing, needs work HARDEN_VM86 - nothing, needs discussion HARDEN_LINK - ACK HARDEN_FIFO - nothing HARDEN_PROC - OK HARDEN_RLIMIT_NPROC - OK, merged into Owl-current HARDEN_SHM - OK ASCII-Armor - nothing SYSFS_RESTRICT - NACK PAX_USERCOPY - DISCUSS PAX_REFCOUNT - DISCUSS 32/64-bit restrictions in containers - NACK log spoofing protection - DISCUSS Global steps could be: * moving Owl to RHEL6/OpenVZ-based kernel from RHEL5/OpenVZ-based. This includes bug fixing, patching userspace, etc. * pushing some enhancements to upstream kernel. * pushing more simple and not disputable enhancements to RHEL6. * backporting accepted enhancements from upstream kernel to RHEL6/OpenVZ. * forwardport old but not accepted by upstream enhancements from PaX/Owl kernels. Only 3 or 4 of enhancements are ready for RHEL6 inclusion - HARDEN_PROC, HARDEN_RLIMIT_NPROC, HARDEN_SHM, and probably HARDEN_LINK. If we want to push anything more, it probably should be discussed in the near time. I'd want to push at least PAX_USERCOPY feature to the upstream and then to RHEL6. I see 2 rough ways to go: 1) - discuss and try to push already accepted features to RHEL6. - move Owl to RHEL6 kernel. - backport/forwardport features to Owl kernel. 2) the same, but +discuss features marked above as DISCUSS on LKML. As last summer showed, the most of time was taken by discussions and disputes on LKML, a bit less was taken by porting GrSecurity/PaX features with stuctural changes. Actual _backporting_ is much faster. So, I think (1) will be fully implemented in less than a summer. LKML discussions could be an "idle" task. The cons are that moving the LKML discussion to the idle state might move actual RHEL6 porting to the Jul/Aug and not finishing it during the summer. -- Vasily
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.