An audit container ID proposal

cyphar — Sun, 01 Apr 2018 12:41:20 +0000

> A new file (containerid) is added to each process's /proc directory; a process's container ID can be set by writing a new value to that file.

Oh dear lord. I haven't been following the proposals as closely since they were reposted, but this is still getting really strange.

I think Casey Schaufler was right in the first review cycle[1]. If we're going to add a process tagging system, we should just add a generic one (like Jose Bollo's PTAGS) and then audit can make use of it. I can think of several things that PTAGS is useful for, while I can only think of one thing that /proc/$pid/containerid would be useful for (and it wouldn't even be useful for *container runtimes* -- only for audit).

From the original thread, the argument against (ab)using something like PTAGS for the purpose of audit was:

> We would love to have a generic kernel facility that the audit subsystem could use to identify containers, but we don't, and previous attempts have failed, so we have to create our own. [...] If a more general solution appears in the future I think we would make every effect to migrate to that; keeping this initial effort small should make that easier.

Effectively being that "there isn't a generic kernel facility, nobody is willing to merge one, but we need something for audit and if there was a generic facility we would use it". Surely someone pushing for an audit-specific process tagging system (called /proc/$pid/containerid even though it's specific to audit) should be enough reason for the relevant maintainers to consider something like PTAGS more seriously?

I'm sure that the PTAGS-audit integration would have some quirks (I imagine CAP_AUDIT_CONTROL will be a point of contention) but I'm sure something like "security.*" xattr namespacing would be applicable.

[1]: https://lwn.net/Articles/740765/

An audit container ID proposal

nix — Fri, 30 Mar 2018 21:36:06 +0000

Also the process can't have started any children or threads yet.

Definitely this requires cooperation, or PTRACE_O_TRACEEXEC to stop it instantly (which seems like horrible overkill, but then, this whole API seems like a horrible hack to me: ptags is obviously better in every way except if you're only looking at auditing and nothing else).

An audit container ID proposal

comio — Fri, 30 Mar 2018 12:03:34 +0000

I think that only the launcher (i.e. docker executable?) will have the CAP_AUDIT_CONTROL enabled. The other processes will just inherit the value during the fork/clone syscall.

An audit container ID proposal

josh — Fri, 30 Mar 2018 11:00:10 +0000

So, you have to have already started the process, and then set the ID from outside the process. That seems like a painful synchronization problem requiring a cooperative process regardless.

LWN: Comments on "An audit container ID proposal"

An audit container ID proposal

An audit container ID proposal

An audit container ID proposal

An audit container ID proposal