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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
