Re: RFC(v2): Audit Kernel Container IDs

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

 



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