[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120502152806.GA12119@albatros>
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.
