From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: auditd and CAP_AUDIT_READ Date: Sat, 17 Nov 2018 12:30:06 -0500 Message-ID: <1681403.nzN13ikyOv@x2> References: <20181115005707.rw6rurt3sh3rmiie@madcap2.tricolour.ca> <20181115234535.7029d8e0@ivy-bridge> <20181116021136.2rnhmbkdezgxsfrj@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181116021136.2rnhmbkdezgxsfrj@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 Thursday, November 15, 2018 9:11:36 PM EST Richard Guy Briggs wrote: > > 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? > > No. CONTROL already did that. READ *was* only ever and still is only > for the bind function of the multicast socket. Auditd does 2 things. It enables auditing and reads from the socket. Because a process has CAP_AUDIT_CONTROL doesn't necessarily mean it has CAP_AUDIT_WRITE. So, I think it would have been benificial and expected that when CAP_AUDIT_READ was created that it also applied to the unicast socket. One less corner case to remember. I could also envision a world where auditd only has read capabilities and no control capabilities. That could all be pushed off into auditctl. -Steve