linux-kernel - 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: <49752b6f-8a77-d1e5-8acb-5a1eed0a992c@suse.de>
Date:   Thu, 19 Oct 2017 10:46:18 +1100
From:   Aleksa Sarai <asarai@...e.de>
To:     Paul Moore <paul@...l-moore.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     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,
        "Eric W. Biederman" <ebiederm@...ssion.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

>> 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

>> ... and orchestration systems should begin as unlabelled
>> processes allowing them to do arbitrary forks.
> 
> My current thinking is that the default state is to start unlabeled (I
> just vomited a little into my SELinux hat); in other words
> init/systemd/PID-1 in the host system starts with an "unset" audit
> container ID.  This not only helps define the host system (anything
> that has an unset audit container ID) but provides a blank slate for
> the orchestrator(s).
> 
>> For nested containers, I actually think the label should be
>> hierarchical, so you can add a label for the new nested container but
>> it still also contains its parents label as well.
> 
> I haven't made up my mind on this completely just yet, but I'm
> currently of the mindset that supporting multiple audit container IDs
> on a given process is not a good idea.

As long as creating a new "container" (that is, changing a process's 
"audit container ID") is an audit event then I think that having a 
hierarchy be explicit is not necessary (userspace audit can figure out 
the hierarchy quite easily -- but also there are cases where thinking of 
it as being hierarchical isn't necessarily correct).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/