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