[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120502161758.GA18569@openwall.com>
Date: Wed, 2 May 2012 20:17:58 +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, Eugene, Petr, all -
On Wed, May 02, 2012 at 07:28:06PM +0400, Vasily Kulikov wrote:
> On Tue, May 01, 2012 at 08:17 +0400, Solar Designer wrote:
> > 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?
Eugene, Petr - any comments?
Vasily - maybe locate and post some links to most-relevant messages from
kernel-hardening to help Eugene and Petr consider this?
> > 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.
I'm OK with this, however please note that it must not be configurable
by the container root user, because the goal here is to reduce the
attack surface of the kernel. This should only be configurable from the
outside (normally before container startup).
> > [...] 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.
Yes. I am upset that we failed to get this feature accepted upstream.
seccomp should also be in there, but it should not be a replacement for
this simple thing.
> If we want to use seccomp itself (e.g. for the latest vsftpd and
> openssh)
We do - once we have it in the kernel. I think seccomp filter is not in
RHEL6 kernels yet? So unless Red Hat intends to backport it, we'll
only gain it much later. I don't think we'll backport it ourselves - or
do you want to?
> we may use it.
Have you checked if it's actually usable for the arch/ABI restrictions
for containers? This was one of the goals, but I don't know if it was
in fact achieved or not.
> > 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.
Yes, but I think it should be something other than a sysctl. OpenVZ's
existing security-relevant restrictions for containers (capabilities,
device types/majors/minors, beancounters) are not in the form of
sysctl's. If we use a sysctl for this, we must make sure that it's
somehow only set before container startup and can't be altered by the
container root user.
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.
