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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1831194.c6xgxYyxjn@sifl>
Date:	Mon, 21 Dec 2015 16:48 -0500
From:	Paul Moore <pmoore@...hat.com>
To:	Richard Guy Briggs <rgb@...hat.com>
Cc:	Steve Grubb <sgrubb@...hat.com>, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org, eparis@...hat.com,
	v.rathor@...il.com, ctcard@...mail.com
Subject: Re: [PATCH V2 1/2] audit: stop an old auditd being starved out by a new auditd

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.}.  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.

> > 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.

-- 
paul moore
security @ redhat

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