Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 2 May 2012 19:28:06 +0400
From: Vasily Kulikov <>
Cc: Petr Matousek <>, Eugene Teo <>
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:

> 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).
> We should do the same.

Yes, I've written about it last July:

> > 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:

Oh, sure, it should be DISCUSS, not nothing.

> > 
> > 
> > 
> > 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.



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.