Date: Tue, 1 May 2012 08:17:23 +0400 From: Solar Designer <solar@...nwall.com> To: owl-dev@...ts.openwall.com Cc: Petr Matousek <pmatouse@...hat.com>, Eugene Teo <eugeneteo@...il.com> Subject: Re: [GSoC] featues to port Vasily, all - On Mon, Apr 30, 2012 at 08:19:16PM +0400, Vasily Kulikov wrote: > 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 You mean "OK", not "nothing"? To me, it looks like this was committed upstream, just without introduction of a CONFIG_* option (but we don't really need it if upstream is OK with not having it). http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d20894a23708c2af75966534f8e4dedb46d48db2 We should do the same. > HARDEN_STACK - nothing, needs work Specifically, we want better support for exec_shield enforcing mode. RHEL5/6 kernels already support exec_shield=2 for this, but glibc would do an mprotect() +x anyway - so we were considering a way to inform glibc of this setting in the kernel, and indeed we'd need to patch glibc to recognize that. Specifically, my suggestion was to use AT_FLAGS. > 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 I want all of the above in Owl. For HARDEN_VM86, this may be per-container, or we may have a global setting to disable VM86 in containers only. You pointed out that there was already CONFIG_VM86 in newer kernels - perhaps not in RHEL6 yet (I did not check)? > ASCII-Armor - nothing We discussed it on kernel-hardening, tried bringing it to LKML, got some criticism from H. Peter Anvin (but not a NACK for the entire approach), tried posting a new revision of the patch (with some of the criticism considered), but did not get any comments on that despite of multiple pings. The last one appears to be: http://www.openwall.com/lists/kernel-hardening/2011/09/23/1 > SYSFS_RESTRICT - NACK > > PAX_USERCOPY - DISCUSS > > PAX_REFCOUNT - DISCUSS > > 32/64-bit restrictions in containers - NACK > > log spoofing protection - DISCUSS Of these, I really want to have "32/64-bit restrictions in containers". It was NACK'ed upstream on the grounds that upstream was getting a more generic solution instead (seccomp v2). seccomp filter is now a reality for upstream, but it's not in RHEL6 yet and I'm not sure whether it actually lets us achieve that goal (I did not check). We still need a simple way to set OpenVZ containers to be 32-bit only or 64-bit only (well, or to specify the ABI e.g. for when we have x32, but that's not important for RHEL6'ish kernels yet). I think we'll be able to get this change into OpenVZ (our immediate upstream). > 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'd like to hear from the Red Hat folks on this. I think at least the BINFMT_ELF_AOUT cleanup may be acceptable for RHEL6 as well and without requiring a discussion on LKML first. > 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. I think that LKML discussions are naturally an idle task, and I don't see how treating them as such makes anything slower. You do need to stay on top of issues brought to LKML, but you also have plenty of time to proceed with getting stuff into our actual kernels in parallel. Indeed, it is possible that you'd end up revising some of the patches for upstream acceptance, but if so you'll be able to get those newer revisions into Owl as well. If upstream acceptance is required for getting the patches into RHEL6, then those changes will have to wait for such acceptance anyway. You can't have stuff accepted upstream instantly even if you make this your highest priority. Thanks, Alexander
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.