On 15/09/28, Paul Moore wrote:
 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(). 
Most other audit_log_start() created messages set portid to zero except
user messages, and those are set using the initiating process' portid
and not the destination id.  So here I think portid should be zero.  The
target task should know its own portid and the netlink field for portid
isn't used for routing to that destination that I can discern from the
netlink code.
 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. 
This could even be renamed audit_make_message() and possibly be
generalized to be useful to audit_log_start(), or rather
audit_buffer_alloc().  Later...
 > > > > 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 ...). 
I had actually named it AUDIT_REPLACE_TEST, but your repeated use of the
term "hijack" swayed me...  I'd still lean towards *_TEST since it is
testing to replace a stale socket and not a live one.
 paul moore 
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545