Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon

On 2020-03-30 10:26, Paul Moore wrote: > On Mon, Mar 30, 2020 at 9:47 AM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > On 2020-03-28 23:11, Paul Moore wrote: > > > On Tue, Mar 24, 2020 at 5:02 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > > On 2020-03-23 20:16, Paul Moore wrote: > > > > > On Thu, Mar 19, 2020 at 6:03 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > > > > On 2020-03-18 18:06, Paul Moore wrote: > > > > > > > > > > ... > > > > > > > > > > > > I hope we can do better than string manipulations in the kernel. I'd > > > > > > > much rather defer generating the ACID list (if possible), than > > > > > > > generating a list only to keep copying and editing it as the record is > > > > > > > sent. > > > > > > > > > > > > At the moment we are stuck with a string-only format. > > > > > > > > > > Yes, we are. That is another topic, and another set of changes I've > > > > > been deferring so as to not disrupt the audit container ID work. > > > > > > > > > > I was thinking of what we do inside the kernel between when the record > > > > > triggering event happens and when we actually emit the record to > > > > > userspace. Perhaps we collect the ACID information while the event is > > > > > occurring, but we defer generating the record until later when we have > > > > > a better understanding of what should be included in the ACID list. > > > > > It is somewhat similar (but obviously different) to what we do for > > > > > PATH records (we collect the pathname info when the path is being > > > > > resolved). > > > > > > > > Ok, now I understand your concern. > > > > > > > > In the case of NETFILTER_PKT records, the CONTAINER_ID record is the > > > > only other possible record and they are generated at the same time with > > > > a local context. > > > > > > > > In the case of any event involving a syscall, that CONTAINER_ID record > > > > is generated at the time of the rest of the event record generation at > > > > syscall exit. > > > > > > > > The others are only generated when needed, such as the sig2 reply. > > > > > > > > We generally just store the contobj pointer until we actually generate > > > > the CONTAINER_ID (or CONTAINER_OP) record. > > > > > > Perhaps I'm remembering your latest spin of these patches incorrectly, > > > but there is still a big gap between when the record is generated and > > > when it is sent up to the audit daemon. Most importantly in that gap > > > is the whole big queue/multicast/unicast mess. > > > > So you suggest generating that record on the fly once it reaches the end > > of the audit_queue just before being sent? That sounds... disruptive. > > Each audit daemon is going to have its own queues, so by the time it > > ends up in a particular queue, we'll already know its scope and would > > have the right list of contids to print in that record. > > I'm not suggesting any particular solution, I'm just pointing out a > potential problem. It isn't clear to me that you've thought about how > we generate a multiple records, each with the correct ACID list > intended for a specific audit daemon, based on a single audit event. > Explain to me how you intend that to work and we are good. Be > specific because I'm not convinced we are talking on the same plane > here. Well, every time a record gets generated, *any* record gets generated, we'll need to check for which audit daemons this record is in scope and generate a different one for each depending on the content and whether or not the content is influenced by the scope.