netdev - Re: RFC(v2): Audit Kernel Container IDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <871sm0j7bm.fsf@xmission.com>
Date:   Wed, 18 Oct 2017 19:43:25 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Aleksa Sarai <asarai@...e.de>
Cc:     Paul Moore <paul@...l-moore.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        cgroups@...r.kernel.org, mszeredi@...hat.com,
        Andy Lutomirski <luto@...nel.org>, jlayton@...hat.com,
        Carlos O'Donell <carlos@...hat.com>,
        API <linux-api@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Viro <viro@...iv.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        linux-audit@...hat.com, Simo Sorce <simo@...hat.com>,
        Development <netdev@...r.kernel.org>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Eric Paris <eparis@...isplace.org>,
        Steve Grubb <sgrubb@...hat.com>, trondmy@...marydata.com
Subject: Re: RFC(v2): Audit Kernel Container IDs

Aleksa Sarai <asarai@...e.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