On 2020-02-13 16:44, Paul Moore wrote: > This is a bit of a thread-hijack, and for that I apologize, but > another thought crossed my mind while thinking about this issue > further ... Once we support multiple auditd instances, including the > necessary record routing and duplication/multiple-sends (the host > always sees *everything*), we will likely need to find a way to "trim" > the audit container ID (ACID) lists we send in the records. The > auditd instance running on the host/initns will always see everything, > so it will want the full container ACID list; however an auditd > instance running inside a container really should only see the ACIDs > of any child containers. Agreed. This should be easy to check and limit, preventing an auditd from seeing any contid that is a parent of its own contid. > For example, imagine a system where the host has containers 1 and 2, > each running an auditd instance. Inside container 1 there are > containers A and B. Inside container 2 there are containers Y and Z. > If an audit event is generated in container Z, I would expect the > host's auditd to see a ACID list of "1,Z" but container 1's auditd > should only see an ACID list of "Z". The auditd running in container > 2 should not see the record at all (that will be relatively > straightforward). Does that make sense? Do we have the record > formats properly designed to handle this without too much problem (I'm > not entirely sure we do)? I completely agree and I believe we have record formats that are able to handle this already. > paul moore - RGB -- Richard Guy Briggs <rgb@xxxxxxxxxx> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
