On Fri, Oct 26, 2018 at 4:13 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 10/25/2018 2:55 PM, Steve Grubb wrote: > > ... > > And historically speaking setting audit loginuid produces a LOGIN > > event, so it only makes sense to consider binding container ID to > > container as a CONTAINER event. For other supplemental records, we name > > things what they are: PATH, CWD, SOCKADDR, etc. So, CONTAINER_ID makes > > sense. CONTAINER_OP sounds like its for operations on a container. Do > > we have any operations on a container? > > The answer has to be "no", because containers are, by emphatic assertion, > not kernel constructs. Any CONTAINER_OP event has to come from user space. > I think. It is very important that we do not confuse operations on the audit container id with operations on the containers themselves. Of course at a higher level, e.g. audit log analysis, we want to equate the two, and if the container runtime which manages the audit container id is sane that should be a reasonable assumption, but in this particular patchset AUDIT_CONTAINER_OP is referring to operations involving just the audit container id. If there is a need for additional container operation auditing (note well that I did not say audit container id here) then those audit records can, and should, be generated by the container runtime itself, similar to what we do with libvirt for virtualization. -- paul moore www.paul-moore.com
