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 15:26:07 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	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.

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.

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?

> Thank you for looking.
> 
> 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/