auditd and CAP_AUDIT_READ

auditd and CAP_AUDIT_READ

[Richard Guy Briggs]

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?  If not, there is no need for it
to check or have CAP_AUDIT_READ.

Having audit_can_read() available in lib/libaudit.c is certainly useful
regardless for other potential libaudit users like systemd.

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: auditd and CAP_AUDIT_READ

[Steve Grubb]

On Wed, 14 Nov 2018 19:57:07 -0500
Richard Guy Briggs <rgb@redhat.com> 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

Re: auditd and CAP_AUDIT_READ

[Paul Moore]

On Thu, Nov 15, 2018 at 5:22 AM Steve Grubb <sgrubb@redhat.com> wrote:
> On Wed, 14 Nov 2018 19:57:07 -0500
> Richard Guy Briggs <rgb@redhat.com> 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.

Establishing an audit daemon connection requires CAP_AUDIT_CONTROL.

-- 
paul moore
www.paul-moore.com

Re: auditd and CAP_AUDIT_READ

[Richard Guy Briggs]

On 2018-11-15 09:51, Steve Grubb wrote:
> On Wed, 14 Nov 2018 19:57:07 -0500
> Richard Guy Briggs <rgb@redhat.com> 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.

So all it needs is CAP_AUDIT_CONTROL as it did previously.  Other user
applications that write AUDIT_USER* messages need CAP_AUDIT_WRITE.

CAP_AUDIT_READ gates the bind function which is used to join a multicast
group (of which there is only one).

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

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.

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

In hindsight, so am I.  This was one of the first things I implemented
when I started working on audit with Eric's enthusiasm and encouragement.

> -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: auditd and CAP_AUDIT_READ

[Steve Grubb]

On Thu, 15 Nov 2018 08:23:46 -0500
Richard Guy Briggs <rgb@redhat.com> 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

Re: auditd and CAP_AUDIT_READ

[Richard Guy Briggs]

On 2018-11-15 23:45, Steve Grubb wrote:
> On Thu, 15 Nov 2018 08:23:46 -0500
> Richard Guy Briggs <rgb@redhat.com> 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?

No.  CONTROL already did that.  READ *was* only ever and still is only
for the bind function of the multicast socket.  Full stop.

> -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: auditd and CAP_AUDIT_READ

[Steve Grubb]

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