Re: RFC(v2): Audit Kernel Container IDs

On Thu, Oct 19, 2017 at 12:25 PM, Eric W. Biederman
[off-list ref] wrote:

Paul Moore [off-list ref] writes:

quoted

On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman
[off-list ref] wrote:

quoted

Aleksa Sarai [off-list ref] writes:

quoted

quoted

quoted

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.

quoted

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.

This is 100% on topic.  I am saying that unless we are planing to have
auditd running in a container with it's own set of rules you probably
don't care about nested containers.  Last time I heard a discussion
about that the term in use was audit namespace.   So I was referring to
that support when I said audit namespace, even if the end result only
loosely fits the term namespace.

My "stay on-topic" comment is directed at, and limited to, your choice
of terminology, not the discussion about container nesting.  I'm
purposefully not using the term "audit namespace" to refer to anything
that Richard has presented, and I'm kindly asking you to do the same,
it simply doesn't fit.

I could be wrong of course.  I don't fully understand what is driving
the desire to connect audit and containers.  But my naive guess is that
one from an audit perspective you don't care about nested containers
unless there is also a nested auditd who is looking at it from a nested
perspective.

Two motivations that are clear to me: the first is the desire to be
able to associate events in the audit log with a container (much like
how the session ID helped us associate events with a login session),
the second is the desire for users to run an audit daemon instance in
their containers to capture audit events generated by their container.
There is also a security certification motivation, see some of Steve's
comments for more on that.

-- 
paul moore
www.paul-moore.com