linux-kernel - Re: [RFC] Make Yama pid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/