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.

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