On Tue, Jan 9, 2018 at 7:16 AM, 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. Two small comments below, but I tend to think we are at a point where you can start cobbling together some prototype/RFC patches. Surely there are going to be a few changes, and new comments, that come out once we see an initial implementation so let's see what those are. > The registration is a u64 representing the audit container identifier > written to a special file in a pseudo filesystem (proc, since PID tree > already exists) representing a process that will become a parent process > in that container. This write might place restrictions on mount > namespaces required to define a container, or at least careful checking > of namespaces in the kernel to verify permissions of the orchestrator so > it can't change its own container ID. A bind mount of nsfs may be > necessary in the container orchestrator's mount namespace. This write > can only happen once per process. > > Note: The justification for using a u64 is that it minimizes the > information printed in every audit record, reducing bandwidth and limits > comparisons to a single u64 which will be faster and less error-prone. I know Steve generally worries about audit record size, which is a perfectly valid concern in this case, I also worry about the additional overhead when we start routing audit records to multiple audit daemons (see my other emails in this thread). > ... > When a container ceases to exist because the last process in that > container has exited log the fact to balance the registration action. > (This is likely needed for certification accountability.) On the "container ceases to exist" point, I expect this "container dead" message to come from the orchestrator and not the kernel itself (I don't want the kernel to have to handle that level of bookkeeping). I imagine this should be similar to what is done for VM auditing with libvirt. -- paul moore www.paul-moore.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
