From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: auditd and CAP_AUDIT_READ Date: Thu, 15 Nov 2018 23:45:35 +0000 Message-ID: <20181115234535.7029d8e0@ivy-bridge> References: <20181115005707.rw6rurt3sh3rmiie@madcap2.tricolour.ca> <20181115095140.35cb44fa@ivy-bridge> <20181115132346.ohiqqtwlk5uox2ig@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181115132346.ohiqqtwlk5uox2ig@madcap2.tricolour.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Richard Guy Briggs Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thu, 15 Nov 2018 08:23:46 -0500 Richard Guy Briggs wrote: > > I thought that the prime audit connection requires a capability > > check to ensure a process without proper privilege does not replace > > the audit daemon...since that's now possible. Are there privilege > > checks for who can connect to the audit socket? Shouldn't that > > process also have CAP_AUDIT_READ since that is what it will be > > doing? > > The only cap that will let a daemon be checked for replacement is > CAP_AUDIT_CONTROL. CAP_AUDIT_READ is only used for the unreliable > reception of multicast audit log records. > > The unicast socket is gated by CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE. > The multicast read-only unreliable socket is gated by > CAP_AUDIT_READ. My understanding was that CAP_AUDIT_READ was required by everything that read, including unicast. That is why it checks that capability CAP_AUDIT_READ. Shouldn't everything reading need that capability? -Steve