From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424058AbcFMVND (ORCPT ); Mon, 13 Jun 2016 17:13:03 -0400 Received: from mail-oi0-f42.google.com ([209.85.218.42]:35788 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423717AbcFMVM6 (ORCPT ); Mon, 13 Jun 2016 17:12:58 -0400 MIME-Version: 1.0 In-Reply-To: <6fd9daef-c9ed-9acb-53b8-438add7cdee8@gmail.com> References: <1465847065-3577-1-git-send-email-toiwoton@gmail.com> <1465847065-3577-2-git-send-email-toiwoton@gmail.com> <6fd9daef-c9ed-9acb-53b8-438add7cdee8@gmail.com> From: Andy Lutomirski Date: Mon, 13 Jun 2016 14:12:37 -0700 Message-ID: Subject: Re: [RFC 01/18] capabilities: track actually used capabilities To: Topi Miettinen Cc: "linux-kernel@vger.kernel.org" , Alexander Viro , Ingo Molnar , Peter Zijlstra , Serge Hallyn , Andrew Morton , Kees Cook , Christoph Lameter , "Serge E. Hallyn" , Andy Shevchenko , "Richard W.M. Jones" , =?UTF-8?Q?Iago_L=C3=B3pez_Galeiras?= , Chris Metcalf , Andy Lutomirski , Jann Horn , "open list:FILESYSTEMS (VFS and infrastructure)" , "open list:CAPABILITIES" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 13, 2016 at 1:45 PM, Topi Miettinen wrote: > On 06/13/16 20:32, Andy Lutomirski wrote: >> On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: >>> Track what capabilities are actually used and present the current >>> situation in /proc/self/status. >> >> What for? > > > Capabilities > [RFC 01/18] capabilities: track actually used capabilities > > Currently, there is no way to know which capabilities are actually used. > Even > the source code is only implicit, in-depth knowledge of each capability must > be used when analyzing a program to judge which capabilities the program > will > exercise." > > Should I perhaps cite some of this in the commit? Yes, but you should also clarify what users are supposed to do with this. Given ambient capabilities, I suspect that you'll find that your patch doesn't actually work very well. For example, if you run a shell script with ambient caps, then you won't notice caps used by short-lived helper processes. > >> >> What is the intended behavior on fork()? Whatever the intended >> behavior is, there should IMO be a selftest for it. >> >> --Andy >> > > The capabilities could be tracked from three points of daemon > initialization sequence onwards: > fork() > setpcap() > exec() > > fork() case would be logical as the /proc entry is per task. But if you > consider the tools to set the capabilities (for example systemd unit > files), there can be between fork() and exec() further preparations > which need more capabilities than the program itself needs. > > setpcap() is probably the real point after which we are interested if > the capabilities are enough. > > The amount of setup between setpcap() and exec() is probably very low. When I asked "what is the intended behavior on fork()?", I mean "what should CapUsed be after fork()?". The answer should be about four words long and should have a test case. There should maybe also be an explanation of why the intended behavior is useful. But, as I said above, I think that you may need to rethink this entirely to make it useful. You might need to do it per process tree or per cgroup or something. --Andy