Re: RFC(v2): Audit Kernel Container IDs

On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman <ebiederm(a)xmission.com&gt; wrote: > Aleksa Sarai <asarai(a)suse.de&gt; 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.