|
Message-ID: <20111123074510.GA2356@albatros> 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.