linux-kernel - Re: [REVIEW][PATCH 0/43] Completing the user namespace

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: <m1iph9ewsy.fsf@fess.ebiederm.org>
Date:	Sun, 08 Apr 2012 14:30:21 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	richard -rw- weinberger <richard.weinberger@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Linux Containers <containers@...ts.linux-foundation.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Cyrill Gorcunov <gorcunov@...nvz.org>
Subject: Re: [REVIEW][PATCH 0/43] Completing the user namespace

richard -rw- weinberger <richard.weinberger@...il.com> writes:

> On Sun, Apr 8, 2012 at 7:10 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> - Capabilities are localized to the current user namespace making
>>  it safe to give the initial user in a user namespace all capabilities.
>>
>
> So, this makes LXC and friends ready for hostile environments?
> IOW a root user (with all capabilities) sitting in his own namespace can no
> longer ham the host?

The user namespace now restricts the root user in a container to being
able to do no more harm than any other user can do.  Additionally suid
executables can no longer lead to having all power on the system.  Which
means that the only privilege escalation attacks available from a
container require kernel bugs.

With my version of user namespaces you no longer have to worry about the
container root writing to files in /proc or /sys and changing the
behavior of the system.  Nor do you have to worry about messages passed
across unix domain sockets to d-bus having a trusted uid and being
allowed to do something nasty.

It allows for applications with no capabilities to use multiple
uids and to implement privilege separation.

I certainly see user namespaces like this as having the potential
to make linux systems more secure.

You will have to make your own threat assessment to decide if that is
enough of an improvement to start deploying containers in what you
consider hostile environments.

For me the big potential I see is that it makes possible the creation of
a container without privilege (today the uid mapping setup still
requires privilege), and it allows a lot of things that the existence of
suid root executables has prevented us from making unprivileged before.

After the core is settled we can start looking at patches to allow
unprivileged creation of other namespaces.  Unprivileged mounts.
Unprivileged use of the networking stack.  Bringing many of the
improvements that linux has seen over the years to unprivileged
users.

I also see great potential for April fools day jokes.  You log in and
try to fix something and discover you are not the root you thought you
were.  Does that count as a hostile environment?

Eric
--
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/