On Tue, Apr 9, 2019 at 3:49 PM Neil Horman [off-list ref] wrote:

On Tue, Apr 09, 2019 at 09:40:58AM -0400, Paul Moore wrote:

quoted

On Tue, Apr 9, 2019 at 8:58 AM Ondrej Mosnacek [off-list ref] wrote:

quoted

On Tue, Apr 9, 2019 at 5:40 AM Richard Guy Briggs [off-list ref] wrote:

quoted

Add audit container identifier support to the action of signalling the
audit daemon.

Since this would need to add an element to the audit_sig_info struct,
a new record type AUDIT_SIGNAL_INFO2 was created with a new
audit_sig_info2 struct.  Corresponding support is required in the
userspace code to reflect the new record request and reply type.
An older userspace won't break since it won't know to request this
record type.

Signed-off-by: Richard Guy Briggs <redacted>

This looks good to me.

Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>

Although I'm wondering if we shouldn't try to future-proof the
AUDIT_SIGNAL_INFO2 format somehow, so that we don't need to add
another AUDIT_SIGNAL_INFO3 when the need arises to add yet-another
identifier to it... The simplest solution I can come up with is to add
a "version" field at the beginning (set to 2 initially), then v<N>_len
at the beginning of data for version <N>. But maybe this is too
complicated for too little gain...

FWIW, I believe the long term solution to this is the fabled netlink
attribute approach that we haven't talked about in some time, but I
keep dreaming about (it has been mostly on the back burner becasue 1)
time and 2) didn't want to impact the audit container ID work).  While
I'm not opposed to trying to make things like this a bit more robust
by adding version fields and similar things, there are still so many
(so very many) problems with the audit kernel/userspace interface that
still need to be addressed.

Agreed, this change as-is is in keeping with the message structure that audit
has today, and so is ok with me, but the long term goal should be a conversion
to netlink attributes for all audit messages.  Thats a big undertaking and
should be addressed separately though.

Yeah, you both have a good point that doing it now and only for this
message is not necessarily better than not doing it at all. And doing
a general overhaul is out of scope for this series, obviously. I
didn't really mind the current solution before and I mind it even less
now, so consider me satisfied :) I was really just thinking out
loud...

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.