Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1234347

Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd

Show all headers | View raw

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd Paul Moore <pmoore@redhat.com> - 2015-09-24 22:10 +0200
  Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new  auditd Richard Guy Briggs <rgb@redhat.com> - 2015-09-25 13:20 +0200
    Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd Paul Moore <pmoore@redhat.com> - 2015-09-25 23:20 +0200
      Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new  auditd Richard Guy Briggs <rgb@redhat.com> - 2015-09-28 13:20 +0200
        Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd Paul Moore <pmoore@redhat.com> - 2015-09-28 21:00 +0200
          Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new  auditd Richard Guy Briggs <rgb@redhat.com> - 2015-09-29 06:40 +0200
            Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd Paul Moore <pmoore@redhat.com> - 2015-09-30 00:30 +0200

csiph-web