[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Nov 2011 11:45:10 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Serge Hallyn <serge.hallyn@...onical.com>
Cc: Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
kernel-hardening@...ts.openwall.com,
"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [RFC] Make Yama pid_ns aware
On Tue, Nov 22, 2011 at 14:10 -0600, Serge Hallyn wrote:
> Quoting Vasiliy Kulikov (segoon@...nwall.com):
> > Hi Serge,
> >
> > On Tue, Nov 22, 2011 at 12:13 -0600, Serge Hallyn wrote:
> > > Quoting Vasiliy Kulikov (segoon@...nwall.com):
> > > > As Yama's sysctls are about defining a security policy for the system,
> > > > it is reasonable to define it per container in case of LXC containers
> > > > (or out-of-tree alternatives like OpenVZ). In my opinion they belong
> > > > to pid namespace. With per-pid_ns sysctls it is possible to create
> > > > multiple containers with different ptrace, /tmp, etc. policies.
> > >
> > > tying the ptrace policy to pidns makes some sense, but is it definately
> > > what we want?
> > >
> > > Is the idea that the container should never be able to bypass the
> > > restrictions, or should root in the container eventually be able to
> > > bypass it as he can on the host?
> >
> > In-container root already has CAP_SYS_PTRACE, so he can avoid the check
> > even if Yama's ptrace policy is enabled.
>
> Well, not necessarily :) But in general.
This is the question is what in-container root is :-) Until LXC root is
restricted up to the case where he is unable to get out of the container
in the mainline kernel, I assume we're talking about an abstract entity
which has full control over the container. It includes stuff like
CAP_CHOWN, CAP_KILL, CAP_SYS_PTRACE, CAP_NET_ADMIN, etc. etc. The
debatable thing is what parts of CAP_SYS_ADMIN belong to in-container
root, like ability to mount/umount. But CAP_SYS_PTRACE is surely
belongs to the in-container root.
> But still, is turning this on and off per-container, and leaving it off
> on the host, something people will reasonably want to do?
Probably we need strict rules like ptrace is relaxed iff in both source
ns and dest ns ptrace is relaxed.
> I'm just
> wondering whether adding the extra data on the pidns is worth it. It's
> fine if it is, but I'm having a hard time imagining someone using it
> like that.
We have already very big net_namespace with all kind of per-ns stuff.
Yama's variables don't significantly increase the size of container.
Actually, what concerns me is not ptrace, but symlink/hardling
protection. There is no interaction between namespaces in case of
containers via symlinks in the basic case. In case of ptrace I don't
think the child ns may weaken the parent ns - child ns may not access
processes of the parent namespace and everything it may ptrace is
already inside of this ns.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
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.
