[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
