linux-kernel - Re: [PATCH 30/43] userns: Fail exec for suid and sgid binaries with ids outside our 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: <m1ehrdrhgr.fsf@fess.ebiederm.org>
Date:	Mon, 23 Apr 2012 19:28:36 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	linux-kernel@...r.kernel.org,
	Linux Containers <containers@...ts.linux-foundation.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	linux-security-module@...r.kernel.org,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 30/43] userns: Fail exec for suid and sgid binaries with ids outside our user namespace.

"Serge E. Hallyn" <serge@...lyn.com> writes:

> Quoting Eric W. Beiderman (ebiederm@...ssion.com):
>> From: Eric W. Biederman <ebiederm@...ssion.com>
>> 
>
> Oh, perhaps this is the right place in the thread to discuss the issue of
> what to do with file capabilities?  I'm ok waiting until the next iteration
> to even discuss it, so long as we start by refusing setting of fcaps by
> any task not in init_user_ns.

For now we do refuse all callers in the init_user_ns because that path
is protected by a capable and not an ns_capable call.

And as a general policy I have pushed all of the changes from capable to
ns_capable out till after we get these other user namespace bits so we
can get the patches reviewed so hopefully don't enable something that is
not safe.

Let's just note here that when we ever get a filesystem mounted in
something other than the init_user_ns or otherwise allow file
capabilities that do not belong to the init_user_ns we need to an
additional exec check to avoid a security issue for processes in the
init_user_ns using those credentials.

The other direction the init_user_ns setting file caps on a file and use
using them in a child namespace seems safe, and practical because of the
way we handle capabilities.  Aka if you have a capability in an outer
user namespace you also have it in a child user namespace.  Which means
a file cap exec today will give you just the capabilities in the child
user namespace.

Something else to think about when we reach filesystems mounted in
different user namespaces (aka unprivileged mounts) are security
labels on files in different user namespaces.  Not any kind of immediate
concern but something we may have to handle eventually.

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/