On Mon, Mar 30, 2020 at 1:49 PM Richard Guy Briggs [off-list ref] wrote:

On 2020-03-30 13:34, Paul Moore wrote:

quoted

On Mon, Mar 30, 2020 at 12:22 PM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-03-30 10:26, Paul Moore wrote:

quoted

On Mon, Mar 30, 2020 at 9:47 AM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-03-28 23:11, Paul Moore wrote:

quoted

On Tue, Mar 24, 2020 at 5:02 PM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-03-23 20:16, Paul Moore wrote:

quoted

On Thu, Mar 19, 2020 at 6:03 PM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-03-18 18:06, Paul Moore wrote:

...

quoted

quoted

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.

That's the problem right there - we don't want to have to generate a
unique record for *each* auditd on *every* record.  That is a recipe
for disaster.

I don't see how we can get around this.

We will already have that problem for PIDs in different PID namespaces.

As I said below, let's not worry about this for all of the
known/current audit records, lets just think about how we solve this
for the ACID related information.

One of the bigger problems with translating namespace info (e.g. PIDs)
across ACIDs is that an ACID - by definition - has no understanding of
namespaces (both the concept as well as any given instance).

We already need to use a different serial number in each auditd/queue,
or else we serialize *all* audit events on the machine and either leak
information to the nested daemons that there are other events happenning
on the machine, or confuse the host daemon because it now thinks that we
are losing events due to serial numbers missing because some nested
daemon issued an event that was not relevant to the host daemon,
consuming a globally serial audit message sequence number.

This isn't really relevant to the ACID lists, but sure.

quoted

Solving this for all of the known audit records is not something we
need to worry about in depth at the moment (although giving it some
casual thought is not a bad thing), but solving this for the audit
container ID information *is* something we need to worry about right
now.

If you think that a different nested contid value string per daemon is
not acceptable, then we are back to issuing a record that has only *one*
contid listed without any nesting information.  This brings us back to
the original problem of keeping *all* audit log history since the boot
of the machine to be able to track the nesting of any particular contid.

I'm not ruling anything out, except for the "let's just completely
regenerate every record for each auditd instance".

What am I missing?  What do you suggest?

I'm missing a solution in this thread, since you are the person
driving this effort I'm asking you to get creative and present us with
some solutions. :)


-- 
paul moore
www.paul-moore.com