Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: RFC(v2): Audit Kernel Container IDs
To:     Paul Moore <paul@paul-moore.com>,
        James Bottomley <James.Bottomley@hansenpartnership.com>
Cc:     cgroups@vger.kernel.org, mszeredi@redhat.com,
        Andy Lutomirski <luto@kernel.org>, jlayton@redhat.com,
        Carlos O'Donell <carlos@redhat.com>,
        API <linux-api@vger.kernel.org>,
        Linux Containers <containers@lists.linux-foundation.org>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        Viro <viro@zeniv.linux.org.uk>,
        David Howells <dhowells@redhat.com>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        linux-audit@redhat.com,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Simo Sorce <simo@redhat.com>,
        Development <netdev@vger.kernel.org>,
        Casey Schaufler <casey@schaufler-ca.com>,
        Eric Paris <eparis@parisplace.org>,
        Steve Grubb <sgrubb@redhat.com>, trondmy@primarydata.com
References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca>
 <75b7d6a6-42ba-2dff-1836-1091c7c024e7@schaufler-ca.com>
 <20171017003340.whjdkqmkw4lydwy7@madcap2.tricolour.ca>
 <2319693.5l3M4ZINGd@x2> <1508243469.6230.24.camel@redhat.com>
 <a07968f6-fef1-f49d-01f1-6c660c0ada20@schaufler-ca.com>
 <1508254120.6230.34.camel@redhat.com>
 <1508255091.3129.27.camel@HansenPartnership.com>
 <CAHC9VhRV9m6-APj3ofMQc22rL-WUoDzB8-urUxryszjCHHHLTg@mail.gmail.com>
From:   Aleksa Sarai <asarai@suse.de>
Message-ID: <49752b6f-8a77-d1e5-8acb-5a1eed0a992c@suse.de>
Date:   Thu, 19 Oct 2017 10:46:18 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAHC9VhRV9m6-APj3ofMQc22rL-WUoDzB8-urUxryszjCHHHLTg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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

From 1581630328388950134@xxx Wed Oct 18 20:57:02 +0000 2017
X-GM-THRID: 1581061469540113612
X-Gmail-Labels: Inbox,Category Forums