Re: RFC(v2): Audit Kernel Container IDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 18, 2017 at 8:43 PM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
> Aleksa Sarai <asarai@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux