Re: RFC(v2): Audit Kernel Container IDs
Aleksa Sarai <asarai(a)suse.de> 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
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''.
Eric