Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd
On Monday, September 28, 2015 07:17:31 AM Richard Guy Briggs wrote:
On 15/09/25, Paul Moore wrote:
...
> The audit_make_reply() function is the wrong thing to be using
here, we
> should create our own buffer from scratch like most other records. Also,
> yes, we want to include the new pid, but I really don't think there is
> any value in including the seqno of the AUDIT_SET/AUDIT_STATUS_PID
> message.
Most other records use audit_log_start(), which isn't what we want here,
since we want to bypass the queue to test if it is still alive. We
don't care if it is delivered. We just care if the socket is still
alive. We don't want a context either.
Yes, that is why I mentioned creating the buffer from scratch.
So, I believ audit_make_reply() can be used just fine, setting
portid,
seq, done and multi to zero.
The 'multi' flag should definitely be set to zero, 'seq' is fine at zero,
but
I think we can do better with 'portid'; we know the 'portid' value so just
use
it in the call to audit_make_reply().
I don't like that we are reusing audit_make_reply() for non-reply netlink
messages, but I'll get over that. This will likely get a revamp when we get
around to a proper fix of the queuing system.
> > > Also, this is more of a attempted hijack message and
not a simple
> > > ping,
> > > right?
> >
> > Ok, so maybe AUDIT_PING is not the appropriate name for it. I don't
> > have a problem changing it, but I think the pid of the hijacker would be
> > useful information to the ping-ee unless the ping message was only ever
> > issues in a contextless kernel-initiated message.
>
> Let's change the message name, this isn't a ping message and we may want
> to have a ping message at some point in the future.
Ok, how about AUDIT_HIJACK_TEST, with a payload of the u32
representation of the PID of the task attempting to replace it.
Why add the TEST? It is a hijack attempt, or at least it is if the record is
emitted successfully :) I would go simply with AUDIT_HIJACK or maybe
AUDIT_REPLACE (or similar) if "hijack" is a bit too inflammatory (it probably
is ...).
--
paul moore
security @ redhat