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 09:51:40 +0000 Message-ID: <20181115095140.35cb44fa@ivy-bridge> References: <20181115005707.rw6rurt3sh3rmiie@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181115005707.rw6rurt3sh3rmiie@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 Wed, 14 Nov 2018 19:57:07 -0500 Richard Guy Briggs wrote: > Hi Steve, > > In commit 183775f155cb96d8012c2d493041a03f1b825b2f ("Do capabilities > check rather than uid") a switch was made from checking "getuid() != > 0" to checking CAP_AUDIT_CONTROL and CAP_AUDIT_READ via > audit_can_control() and audit_can_read(). > > Does auditd use the multicast socket? No. It uses the prime guaranteed delivery netlink connection. > If not, there is no need for it to check or have CAP_AUDIT_READ 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? > Having audit_can_read() available in lib/libaudit.c is certainly > useful regardless for other potential libaudit users like systemd. I have never tried to make libaudit work with multicast sockets because I'm against the whole concept. -Steve