Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756104AbcKWA7g (ORCPT ); Tue, 22 Nov 2016 19:59:36 -0500 Received: from mail-oi0-f46.google.com ([209.85.218.46]:33343 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752517AbcKWA7E (ORCPT ); Tue, 22 Nov 2016 19:59:04 -0500 MIME-Version: 1.0 In-Reply-To: References: <1478647728-30357-1-git-send-email-john.stultz@linaro.org> <20161109000342.GA42532@ast-mbp.thefacebook.com> From: John Stultz Date: Tue, 22 Nov 2016 16:57:48 -0800 Message-ID: Subject: Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups To: Andy Lutomirski Cc: Alexei Starovoitov , Andy Lutomirski , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Daniel Mack , "David S. Miller" , kafai@fb.com, Florian Westphal , Harald Hoyer , Network Development , Sargun Dhillon , Pablo Neira Ayuso , lkml , Tejun Heo , Li Zefan , Jonathan Corbet , "open list:CONTROL GROUP (CGROUP)" , Android Kernel Team , Rom Lemarchand , Colin Cross , Dmitry Shmidt , Todd Kjos , Christian Poetzsch , Amit Pundir , Dmitry Torokhov , Kees Cook , "Serge E . Hallyn" , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2645 Lines: 61 On Tue, Nov 8, 2016 at 4:12 PM, Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 4:03 PM, Alexei Starovoitov > wrote: >> On Tue, Nov 08, 2016 at 03:51:40PM -0800, Andy Lutomirski wrote: >>> >>> I hate to say it, but I think I may see a problem. Current >>> developments are afoot to make cgroups do more than resource control. >>> For example, there's Landlock and there's Daniel's ingress/egress >>> filter thing. Current cgroup controllers can mostly just DoS their >>> controlled processes. These new controllers (or controller-like >>> things) can exfiltrate data and change semantics. >>> >>> Does anyone have a security model in mind for these controllers and >>> the cgroups that they're attached to? I'm reasonably confident that >>> CAP_SYS_RESOURCE is not the answer... >> >> and specifically the answer is... ? >> Also would be great if you start with specifying the question first >> and the problem you're trying to solve. >> > > I don't have a good answer right now. Here are some constraints, though: > > 1. An insufficiently privileged process should not be able to move a > victim into a dangerous cgroup. > > 2. An insufficiently privileged process should not be able to move > itself into a dangerous cgroup and then use execve to gain privilege > such that the execve'd program can be compromised. > > 3. An insufficiently privileged process should not be able to make an > existing cgroup dangerous in a way that could compromise a victim in > that cgroup. > > 4. An insufficiently privileged process should not be able to make a > cgroup dangerous in a way that bypasses protections that would > otherwise protect execve() as used by itself or some other process in > that cgroup. > > Keep in mind that "dangerous" may apply to a cgroup's descendents in > addition to the cgroup being controlled. Sorry for taking awhile to get back to you here. I'm a little befuddled as to what next steps I should consider (and honestly, I'm not totally sure I really grok your concern here, particularly what you mean with "dangrous cgroups"). So is going back to the CAP_CGROUP_MIGRATE approach (to properly separate "sufficiently" from "insufficiently privileged") better? Or something closer to the original method Android used of each cgroup having an allow_attach() check which could determine what is sufficiently privledged for the respective level of danger the cgroup might poise? Or just stepping back, what method would you imagine to be reasonable to allow a specified task to migrate other tasks between cgroups without it having to be root/suid? thanks -john