linux-kernel - Re: [RFC][PATCH] Fix cap_capable to only allow owners in the parent user namespace to have caps.

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]

Date:	Fri, 14 Dec 2012 07:47:03 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	containers@...ts.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC][PATCH] Fix cap_capable to only allow owners in the parent user namespace to have caps.

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

> Quoting Eric W. Biederman (ebiederm@...ssion.com):
>> "Serge E. Hallyn" <serge@...lyn.com> writes:
>> 
>> > Quoting Eric W. Biederman (ebiederm@...ssion.com):
>> >> 
>> >> Andy Lutomirski pointed out that the current behavior of allowing the
>> >> owner of a user namespace to have all caps when that owner is not in a
>> >> parent user namespace is wrong.
>> >
>> > To make sure I understand right, the issue is when a uid is mapped
>> > into multiple namespaces.
>> 
>> Yes.
>> 
>> i.e. uid 1000 in ns1 may own ns2, but uid 1000 in ns3 does not?
>> 
>> I am not certain of your example.
>> 
>> The simple case is:
>> 
>> init_user_ns:
>>      child_user_ns1 (owned by uid == 0 [in all user namespaces])
>>            child_user_ns2 (owned by uid == 0 [ in all user namespaces])
>> 
>> 
>> root (uid == 0) in child_user_ns2 has all rights over anything in
>> child_user_ns1.
>
> Well that is only if there was no mapping.  (since we're comparing
> kuids, not uid_ts).  right?  If you didn't map uid 0 in child_user_ns2
> to another id in the parent ns, you weren't all *that* serious about
> isolating the ns.
>
> The case I was thinking is
>
>   init_user_ns:  [0-uidmax]
>       child_user_ns1  [100000-199999]
>       child_user_ns2  [100000-199999]
>         child_user_ns3  [200000-299999]
>
> with unfortunate mappings  - ns1 and ns2 should have had nonoverlapping
> ranges, but in any case now uid 1000 in ns1 can exert privilege over
> ns3.  Again, uids comparisons will succeed for file access anyway, so
> ns1 can 0wn ns2 and ns3 other ways.

Yes yours is the more realistic scenario.  Mine was simplified to be clear.

> Heck I'm starting to think the bug is a feature - surely given the
> mappings above I meant for ns1 and ns2 to bleed privilege to each
> other?

The serious problem is that privileges can bleed up. A user in 
ns3 can wind up owning ns2 or ns1.  Which totally defeats the permission
model.  You have CAP_DAC_OVERRIDE so you don't even need access to files
you own, etc, etc.

Or the more fun version as root:
	/* Drop all privs */
	pid = clone(CLONE_NEWUSER);
	if (pid == 0) {
		/* Have all privs! Bahaha */
	}

Which makes dropping capabilies a joke.

And since up to through 3.7 the only user that can create a user namespace
is root that is a very realistic scenario.  It doesn't work against the
initial user namespace thankfully, but in v3.7 it works against every
other user namespace.

To keep user namespaces safe we need to maintain the invariant that a
child user namespace can not get capapabilities in it's parent user
namespace.

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/