From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <871sm0j7bm.fsf@xmission.com> References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> <75b7d6a6-42ba-2dff-1836-1091c7c024e7@schaufler-ca.com> <20171017003340.whjdkqmkw4lydwy7@madcap2.tricolour.ca> <2319693.5l3M4ZINGd@x2> <1508243469.6230.24.camel@redhat.com> <1508254120.6230.34.camel@redhat.com> <1508255091.3129.27.camel@HansenPartnership.com> <49752b6f-8a77-d1e5-8acb-5a1eed0a992c@suse.de> <871sm0j7bm.fsf@xmission.com> From: Paul Moore Date: Thu, 19 Oct 2017 11:36:39 -0400 Message-ID: Subject: Re: RFC(v2): Audit Kernel Container IDs To: Aleksa Sarai , "Eric W. Biederman" Cc: James Bottomley , cgroups@vger.kernel.org, mszeredi@redhat.com, Andy Lutomirski , jlayton@redhat.com, "Carlos O'Donell" , API , Linux Containers , Linux Kernel , Viro , David Howells , Linux FS Devel , linux-audit@redhat.com, Simo Sorce , Development , Casey Schaufler , Eric Paris , Steve Grubb , trondmy@primarydata.com Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman wrote: > Aleksa Sarai writes: >>>> The security implications are that anything that can change the label >>>> could also hide itself and its doings from the audit system and thus >>>> would be used as a means to evade detection. I actually think this >>>> means the label should be write once (once you've set it, you can't >>>> change it) ... >>> >>> Richard and I have talked about a write once approach, but the >>> thinking was that you may want to allow a nested container >>> orchestrator (Why? I don't know, but people always want to do the >>> craziest things.) and a write-once policy makes that impossible. If >>> we punt on the nested orchestrator, I believe we can seriously think >>> about a write-once policy to simplify things. >> >> Nested containers are a very widely used use-case (see LXC system containers, >> inside of which people run other container runtimes). So I would definitely >> consider it something that "needs to be supported in some way". While the LXC >> guys might be a *tad* crazy, the use-case isn't. :P No worries, we're all a little crazy in our own special ways ;) Kidding aside, thanks for explaining the use case. > Of course some of that gets to running auditd inside a container which > we don't have yet either. > > So I think to start it is perfectly fine to figure out the non-nested > case first and what makes sense there. Then to sort out the nested > container case. > > The solution might be that a process gets at most one id per ``audit > namespace''. In an attempt to stay on-topic, let's try to stick with "audit container ID" or "container ID" if you must. I really want to avoid the term "audit namespace" simply because the term "namespace" implies some things which we aren't planning on doing. -- paul moore www.paul-moore.com