From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424390AbcFMVs0 (ORCPT ); Mon, 13 Jun 2016 17:48:26 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36444 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422955AbcFMVsY (ORCPT ); Mon, 13 Jun 2016 17:48:24 -0400 Subject: Re: [RFC 01/18] capabilities: track actually used capabilities To: Andy Lutomirski 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> 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" From: Topi Miettinen Openpgp: id=A0F2EB0D8452DA908BEC8E911CF9ADDBD610E936 Message-ID: <18dc7bfc-7533-1008-4091-5ae0560df21c@gmail.com> Date: Mon, 13 Jun 2016 21:48:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/13/16 21:12, Andy Lutomirski wrote: > 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. > Right, I suppose this model works well only within a single process, or where the helper processes are always unprivileged (like Xorg runs xkbcomp) or less privileged. >> >>> >>> 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. In this model: fork: no change setpcap: no change exec: reset But I hadn't thought that much where the reset happens. > > 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 > I'd actually prefer the cgroup approach. Though that's much more work than this simple patch which already gives somewhat useful information in limited cases (once the logic is correct). -Topi