From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752318AbcGKTsA (ORCPT ); Mon, 11 Jul 2016 15:48:00 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36216 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751802AbcGKTr6 (ORCPT ); Mon, 11 Jul 2016 15:47:58 -0400 Subject: Re: [PATCH] capabilities: audit capability use To: Tejun Heo References: <1468235672-3745-1-git-send-email-toiwoton@gmail.com> <20160711170711.GB3337@htj.duckdns.org> Cc: linux-kernel@vger.kernel.org, ebiederm@xmission.com, pmladek@suse.com, luto@kernel.org, serge@hallyn.com, keescook@chromium.org, Paul Moore , Eric Paris , Li Zefan , Johannes Weiner , Serge Hallyn , "moderated list:AUDIT SUBSYSTEM" , "open list:CONTROL GROUP (CGROUP)" , "open list:CAPABILITIES" From: Topi Miettinen Openpgp: id=A0F2EB0D8452DA908BEC8E911CF9ADDBD610E936 Message-ID: <683cdbb9-c414-07c7-16d3-41c4138ddf8d@gmail.com> Date: Mon, 11 Jul 2016 19:47:44 +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: <20160711170711.GB3337@htj.duckdns.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/11/16 17:09, Tejun Heo wrote: > Hello, > > On Mon, Jul 11, 2016 at 02:14:31PM +0300, Topi Miettinen wrote: >> [ 28.443674] audit: type=1327 audit(1468234333.144:520): proctitle=6D6B6E6F64002F6465762F7A5F343639006300310032 >> [ 28.465888] audit: type=1330 audit(1468234333.144:520): cap_used=0000000008000000 >> [ 28.482080] audit: type=1331 audit(1468234333.144:520): cgroups=:/test; > > Please don't put additions of the two different audit types into one > patch and I don't think the cgroup audit logging makes much sense. > Without logging all migrations, it doesn't help auditing all that > much. Also, printing all cgroup membership like that can be > problematic for audit it can be arbitrarily long. > > Thanks. > It's really critical to be able to associate a task in the logs to cgroups which were valid that time. Or can we infer somehow what cgroups a task was taking part, long time after task exit? Perhaps task cgroup membership changes and changes in available cgroups should be logged too? Some kind of cgroup IDs could be logged instead of long paths. Then these IDs should be reliably resolvable to paths offline somehow. How usual migrations between cgroups are? Why would a task ever move from (say) systemd/system.slice/smartd.service to anywhere else? -Topi