On Thu, 12 Oct 2017 10:14:00 -0400 Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > Containers are a userspace concept. The kernel knows nothing of them. > > The Linux audit system needs a way to be able to track the container > provenance of events and actions. Audit needs the kernel's help to do > this. > > Since the concept of a container is entirely a userspace concept, a > registration from the userspace container orchestration system initiates > this. This will define a point in time and a set of resources > associated with a particular container with an audit container ID. I don't think this has anything to do with containers directly. If i read it right you need a subtree of stuff to be asigned a (possibly irrevocable) magic identifier that you can use for other purposes. Traditional Unix in the more 'secure' space had that decades ago in the form of luid. At login time you did a setluid() and that set an irrevocable tag onthe session which was (traditionally) the uid of the login process so that audit and other related tools always knew how to tie the process back to the login session. That doesn't quite work as of itself (if you login you'd get luid set and not be able to change it for the container), but it seems something similarly trivial like a "setauditid(void)" would do the trick providing the kernel picked the UUID randomly [otherwise I can copy another known UUID to confuse or hide]. As you say a container is a userspace concept. So IMHO any audit interface should be about auditing and what needs tracking, not about containers. If the container management tool wants to set a suitable tag then let it. If not then it doesn't. Then it's a simple as checking CAP_AUDIT_WRITE to see if you are allowed to setauditit(), generating a random uuid and a matching getauditid() to copy it back. Alan -- 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
