From: Steve Grubb <sgrubb@redhat.com>
To: Paul Moore <pmoore@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
linux-audit@redhat.com, linux-kernel@vger.kernel.org,
eparis@redhat.com, v.rathor@gmail.com, ctcard@hotmail.com
Subject: Re: [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd
Date: Mon, 21 Dec 2015 17:18:15 -0500 [thread overview]
Message-ID: <3132444.Y0z3o3Cmva@x2> (raw)
In-Reply-To: <1831194.c6xgxYyxjn@sifl>
On Monday, December 21, 2015 04:48:00 PM Paul Moore wrote:
> On Wednesday, December 16, 2015 11:23:19 AM Steve Grubb wrote:
> > On Wednesday, December 16, 2015 10:42:32 AM Richard Guy Briggs wrote:
> > > Nothing prevents a new auditd starting up and replacing a valid
> > > audit_pid when an old auditd is still running, effectively starving out
> > > the old auditd since audit_pid no longer points to the old valid auditd.
> >
> > I guess the first question is why do we allow something to start up a new
> > auditd without killing off the old one? Would that be a simpler fix?
>
> I imagine there might be scenarios where you need to forcibly kill an
> instance of auditd such that things might not get fully cleaned up in the
> kernel, audit_{pid,sock,etc.}.
But the first time an event is sent and auditd doesn't exist, it resets the
audit_pid to 0.
static void kauditd_send_skb(struct sk_buff *skb)
{
int err;
/* take a reference in case we can't send it and we want to hold it */
skb_get(skb);
err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
if (err < 0) {
BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
if (audit_pid) {
pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
audit_log_lost("auditd disappeared");
audit_pid = 0;
audit_sock = NULL;
}
> Keeping the ability to reset the kernel's auditd state, even when the kernel
> *thinks* auditd is still alive might be a nice thing to keep around for a
> while longer.
I'm just thinking its rare that anyone would try to steal away the audit
socket. Its more work for everyone to create a new event and send it than to
just not allow it. you can even force an event with "auditctl -m test" which
should reset the pid if the kernel was out of sync.
The
> > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > index 843540c..cf84991 100644
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -70,6 +70,7 @@
> > >
> > > #define AUDIT_TTY_SET 1017 /* Set TTY auditing status */
> > > #define AUDIT_SET_FEATURE 1018 /* Turn an audit feature on or off
*/
> > > #define AUDIT_GET_FEATURE 1019 /* Get which features are enabled
*/
> > >
> > > +#define AUDIT_REPLACE 1020 /* Replace auditd if this pack...
*/
> >
> > In every case, events in the 1000 block are to configure the kernel or to
> > ask the kernel a question. This is user space initiating. Kernel
> > initiating
> > events are in the 1300 block of numbers.
>
> Change the audit event number as Steve suggests and I'll toss the patches
> into my audit next queue, although considering we are at 4.4-rc6 at
> present, I'll probably hold this until after the merge window closes,
> meaning it is 4.6 material.
next prev parent reply other threads:[~2015-12-21 22:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 15:42 [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd Richard Guy Briggs
2015-12-16 15:42 ` [PATCH V2 2/2] audit: log failed attempts to change audit_pid configuration Richard Guy Briggs
2015-12-16 15:42 ` Richard Guy Briggs
2015-12-16 16:23 ` [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd Steve Grubb
2015-12-21 21:48 ` Paul Moore
2015-12-21 22:18 ` Steve Grubb [this message]
2015-12-21 22:36 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3132444.Y0z3o3Cmva@x2 \
--to=sgrubb@redhat.com \
--cc=ctcard@hotmail.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmoore@redhat.com \
--cc=rgb@redhat.com \
--cc=v.rathor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.