From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] capabilities: add capability cgroup controller Date: Fri, 24 Jun 2016 12:21:33 -0500 Message-ID: <87mvmaa4f6.fsf@x220.int.ebiederm.org> References: <1466694434-1420-1-git-send-email-toiwoton@gmail.com> <20160623213819.GP3262@mtj.duckdns.org> <53377cda-9afe-dad4-6bbb-26affd64cb3a@gmail.com> <20160624154830.GX3262@mtj.duckdns.org> <20160624155916.GA8759@mail.hallyn.com> <20160624163527.GZ3262@mtj.duckdns.org> <20160624165910.GA9675@mail.hallyn.com> Mime-Version: 1.0 Return-path: In-Reply-To: <20160624165910.GA9675@mail.hallyn.com> (Serge E. Hallyn's message of "Fri, 24 Jun 2016 11:59:10 -0500") Sender: linux-doc-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Serge E. Hallyn" Cc: Tejun Heo , Topi Miettinen , linux-kernel@vger.kernel.org, luto@kernel.org, keescook@chromium.org, Jonathan Corbet , Li Zefan , Johannes Weiner , Serge Hallyn , James Morris , Andrew Morton , David Howells , David Woodhouse , Ard Biesheuvel , "Paul E. McKenney" , Petr Mladek , "open list:DOCUMENTATION" , "open list:CONTROL GROUP (CGROUP)" , "open list:CAPABILITIES" "Serge E. Hallyn" writes: > Quoting Tejun Heo (tj@kernel.org): >> Hello, >> >> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote: >> > Quoting Tejun Heo (tj@kernel.org): >> > > But isn't being recursive orthogonal to using cgroup? Why not account >> > > usages recursively along the process hierarchy? Capabilities don't >> > > have much to do with cgroup but everything with process hierarchy. >> > > That's how they're distributed and modified. If monitoring their >> > > usages is necessary, it makes sense to do it in the same structure. >> > >> > That was my argument against using cgroups to enforce a new bounding >> > set. For tracking though, the cgroup process tracking seems as applicable >> > to this as it does to systemd tracking of services. It tracks a task and >> > the children it forks. >> >> Just monitoring is less jarring than implementing security enforcement >> via cgroup, but it is still jarring. What's wrong with recursive >> process hierarchy monitoring which is in line with the whole facility >> is implemented anyway? > > As I think Topi pointed out, one shortcoming is that if there is a short-lived > child task, using its /proc/self/status is racy. You might just miss that it > ever even existed, let alone that the "application" needed it. > > Another alternative we've both mentioned is to use systemtap. That's not > as nice a solution as a cgroup, but then again this isn't really a common > case, so maybe it is precisely what a tracing infrastructure is meant for. Hmm. We have capability use wired up into auditing. So we might be able to get away with just adding an appropriate audit message in commoncap.c:cap_capable that honors the audit flag and logs an audit message. The hook in selinux already appears to do that. Certainly audit sounds like the subsystem for this kind of work, as it's whole point in life is logging things, then something in userspace can just run over the audit longs and build a nice summary. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751799AbcFXReR (ORCPT ); Fri, 24 Jun 2016 13:34:17 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:49410 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751452AbcFXReO (ORCPT ); Fri, 24 Jun 2016 13:34:14 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Serge E. Hallyn" Cc: Tejun Heo , Topi Miettinen , linux-kernel@vger.kernel.org, luto@kernel.org, keescook@chromium.org, Jonathan Corbet , Li Zefan , Johannes Weiner , Serge Hallyn , James Morris , Andrew Morton , David Howells , David Woodhouse , Ard Biesheuvel , "Paul E. McKenney" , Petr Mladek , "open list\:DOCUMENTATION" , "open list\:CONTROL GROUP \(CGROUP\)" , "open list\:CAPABILITIES" References: <1466694434-1420-1-git-send-email-toiwoton@gmail.com> <20160623213819.GP3262@mtj.duckdns.org> <53377cda-9afe-dad4-6bbb-26affd64cb3a@gmail.com> <20160624154830.GX3262@mtj.duckdns.org> <20160624155916.GA8759@mail.hallyn.com> <20160624163527.GZ3262@mtj.duckdns.org> <20160624165910.GA9675@mail.hallyn.com> Date: Fri, 24 Jun 2016 12:21:33 -0500 In-Reply-To: <20160624165910.GA9675@mail.hallyn.com> (Serge E. Hallyn's message of "Fri, 24 Jun 2016 11:59:10 -0500") Message-ID: <87mvmaa4f6.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bGUzL-0003Cr-8Q;;;mid=<87mvmaa4f6.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18kATn5XQ4TcJa6ebF66gNmEgjbFhuCA68= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMDrugObfuBody_04 obfuscated drug references X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Serge E. Hallyn" X-Spam-Relay-Country: X-Spam-Timing: total 1045 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 4.0 (0.4%), b_tie_ro: 2.9 (0.3%), parse: 1.32 (0.1%), extract_message_metadata: 58 (5.6%), get_uri_detail_list: 2.8 (0.3%), tests_pri_-1000: 23 (2.2%), tests_pri_-950: 2.1 (0.2%), tests_pri_-900: 1.69 (0.2%), tests_pri_-400: 83 (8.0%), check_bayes: 81 (7.8%), b_tokenize: 27 (2.6%), b_tok_get_all: 27 (2.6%), b_comp_prob: 6 (0.6%), b_tok_touch_all: 16 (1.5%), b_finish: 0.98 (0.1%), tests_pri_0: 859 (82.3%), check_dkim_signature: 0.85 (0.1%), check_dkim_adsp: 27 (2.5%), tests_pri_500: 7 (0.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] capabilities: add capability cgroup controller X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Serge E. Hallyn" writes: > Quoting Tejun Heo (tj@kernel.org): >> Hello, >> >> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote: >> > Quoting Tejun Heo (tj@kernel.org): >> > > But isn't being recursive orthogonal to using cgroup? Why not account >> > > usages recursively along the process hierarchy? Capabilities don't >> > > have much to do with cgroup but everything with process hierarchy. >> > > That's how they're distributed and modified. If monitoring their >> > > usages is necessary, it makes sense to do it in the same structure. >> > >> > That was my argument against using cgroups to enforce a new bounding >> > set. For tracking though, the cgroup process tracking seems as applicable >> > to this as it does to systemd tracking of services. It tracks a task and >> > the children it forks. >> >> Just monitoring is less jarring than implementing security enforcement >> via cgroup, but it is still jarring. What's wrong with recursive >> process hierarchy monitoring which is in line with the whole facility >> is implemented anyway? > > As I think Topi pointed out, one shortcoming is that if there is a short-lived > child task, using its /proc/self/status is racy. You might just miss that it > ever even existed, let alone that the "application" needed it. > > Another alternative we've both mentioned is to use systemtap. That's not > as nice a solution as a cgroup, but then again this isn't really a common > case, so maybe it is precisely what a tracing infrastructure is meant for. Hmm. We have capability use wired up into auditing. So we might be able to get away with just adding an appropriate audit message in commoncap.c:cap_capable that honors the audit flag and logs an audit message. The hook in selinux already appears to do that. Certainly audit sounds like the subsystem for this kind of work, as it's whole point in life is logging things, then something in userspace can just run over the audit longs and build a nice summary. Eric