From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic316-20.consmr.mail.bf2.yahoo.com ([74.6.130.194]:38063 "EHLO sonic316-20.consmr.mail.bf2.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752241AbeDSBP5 (ORCPT ); Wed, 18 Apr 2018 21:15:57 -0400 Subject: Re: [RFC PATCH ghak32 V2 01/13] audit: add container id To: Paul Moore Cc: Richard Guy Briggs , cgroups@vger.kernel.org, containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, ebiederm@xmission.com, luto@kernel.org, jlayton@redhat.com, carlos@redhat.com, dhowells@redhat.com, viro@zeniv.linux.org.uk, simo@redhat.com, Eric Paris , serge@hallyn.com References: <32d3e7a6-36f0-571a-bb91-67f746c7eafa@schaufler-ca.com> From: Casey Schaufler Message-ID: <1adffa90-020d-54e1-fbf5-7fc929ccb44c@schaufler-ca.com> Date: Wed, 18 Apr 2018 18:15:46 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 4/18/2018 5:46 PM, Paul Moore wrote: > On Wed, Apr 18, 2018 at 8:41 PM, Casey Schaufler wrote: >> On 4/18/2018 4:47 PM, Paul Moore wrote: >>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: >>>> Implement the proc fs write to set the audit container ID of a process, >>>> emitting an AUDIT_CONTAINER record to document the event. >>>> ... >>>> >>>> diff --git a/include/linux/sched.h b/include/linux/sched.h >>>> index d258826..1b82191 100644 >>>> --- a/include/linux/sched.h >>>> +++ b/include/linux/sched.h >>>> @@ -796,6 +796,7 @@ struct task_struct { >>>> #ifdef CONFIG_AUDITSYSCALL >>>> kuid_t loginuid; >>>> unsigned int sessionid; >>>> + u64 containerid; >>> This one line addition to the task_struct scares me the most of >>> anything in this patchset. Why? It's a field named "containerid" in >>> a perhaps one of the most widely used core kernel structures; the >>> possibilities for abuse are endless, and it's foolish to think we >>> would ever be able to adequately police this. >> If we can get the LSM infrastructure managed task blobs from >> module stacking in ahead of this we could create a trivial security >> module to manage this. It's not as if there aren't all sorts of >> interactions between security modules and the audit system already. > While yes, there are plenty of interactions between the two, it is > possible to use audit without the LSMs and I would like to preserve > that. Fair enough. > Further, I don't want to entangle two very complicated code > changes or make the audit container ID effort dependent on LSM > stacking. Also fair, although the use case for container audit IDs is already pulling in audit, namespaces (yeah, I know it's not necessary for a container to use namespaces) security modules (stacked and/or namespaced), cgroups and who knows what else. > You're a good salesman Casey, but you're not that good ;) I have to keep the skills sharpened somehow! OK, I'll grant that this isn't a great fit.