Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ