linux-kernel - Re: [RFC PATCH 1/2] devices cgroup: allow can_attach() if ns

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131104215135.GA26190@mail.hallyn.com>
Date:	Mon, 4 Nov 2013 21:51:35 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Serge Hallyn <serge.hallyn@...ntu.com>,
	Containers <containers@...ts.linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Victor Marmol <vmarmol@...gle.com>,
	Stéphane Graber <stgraber@...ntu.com>,
	Rohit Jnagal <jnagal@...gle.com>
Subject: Re: [RFC PATCH 1/2] devices cgroup: allow can_attach() if ns_capable

Quoting Tejun Heo (tj@...nel.org):
> Hello, Serge.
> 
> On Tue, Jul 23, 2013 at 3:28 PM, Serge Hallyn <serge.hallyn@...ntu.com> wrote:
> > On Tue, Jul 23, 2013 at 02:04:26PM -0500, Serge Hallyn wrote:
> > > If task A is uid 1000 on the host, and creates task B as uid X in a new
> > > user namespace, then task A, still being uid 1000 on the host, is
> > > privileged with respect to B and his namespace - i.e.
> > > ns_capable(B->userns, CAP_SYS_ADMIN) is true.
> 
> >> Well, that also is the exact type of priv delegation we're moving away
> >> from, so....
> >
> > I think that's unreasonable, but I guess I'll have to go reread the
> > old thread.
> 
> Yeah, please do. I think the case is pretty strong for disallowing
> delegation of cgroup directories to !root (or whatever CAP it should
> be) users. It's inherently unsafe for some controllers and ends up
> leaking kernel implementation details into regular binaries thus
> cementing those leaked details as APIs, which is a giant no-no.

Hi Tejun,

So to come back to this...  At plumbers, I believe you were not present
at the 'let me contain that for you' session.  There the "delegation is
not safe" topic came up.  When pressed, the only example that came up
was (IIRC) having to do with an rt scheduling issue which, all agreed,
was a bug in the implementation which should be fixed, rather than a valid
reason to say that delegation of cgroups should be fundamentally not supported.

Do you have a list of such issues which you see with delegation?  That is,
cases where, if ownership of a subtree is granted to a non-root user,
that user can affect tasks owned by other users who are in other
cgroups?

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