Date: Wed, 2 May 2012 19:28:06 +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: Re: [GSoC] featues to port Solar, all - On Tue, May 01, 2012 at 08:17 +0400, Solar Designer wrote: > > BINFMT_ELF_AOUT (cleanup) - nothing > > You mean "OK", not "nothing"? No, I mean "nothing", for the cleanup patch. I've already sent a patch (twice, iirc), but with no answer: http://www.openwall.com/lists/kernel-hardening/2011/08/08/1 > 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. Yes, I've written about it last July: http://www.openwall.com/lists/kernel-hardening/2011/07/30/1 > > 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. I agree it can be AT_FLAGS. But is it convenient for RH folks? > For HARDEN_VM86, this may be per-container, or we may have a global > setting to disable VM86 in containers only. Well, for upstream I'd say it should be per-container because of possible container-in-container hiararchies. But in RHEL/OpenVZ containers' hierarchy is flat with one level of containers. Specifically, for RHEL6/OpenVZ the latter is OK, but it might be not compatible with the following RHEL7, RHEL8, etc. versions with probably possible nested containers. So, I'd say - a per-container variable. > You pointed out that there was already CONFIG_VM86 in newer kernels - > perhaps not in RHEL6 yet (I did not check)? There is CONFIG_VM86 in RHEL6 kernel. > > 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 Oh, sure, it should be DISCUSS, not nothing. > > 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). I'd say seccomp touches too many code for such a relatively simple task. If we want to use seccomp itself (e.g. for the latest vsftpd and openssh) we may use it. > 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 second that we should use a per-container (pid_ns) sysctl for that with arch/ABI identifier. Thanks, -- 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.