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

["Serge E. Hallyn" <serge@hallyn.com>]

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serge@hallyn.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@xmission.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