linux-kernel - Re: [RFC PATCH] audit: Send netlink ACK before setting connection in 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]

Date:   Tue, 17 Oct 2023 17:20:29 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Chris Riches <chris.riches@...anix.com>
Cc:     audit@...r.kernel.org, Eric Paris <eparis@...hat.com>,
        jonathan.davies@...anix.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] audit: Send netlink ACK before setting connection in auditd_set

On Tue, Oct 17, 2023 at 9:49 AM Chris Riches <chris.riches@...anix.com> wrote:
> On 16/10/2023 21:16, Paul Moore wrote:
>  >> While typing it out manually, I noticed that
>  >> the condition for sending the ACK isn't correct - if NLM_F_ACK is 0 to
>  >> begin with, then ack will be false to begin with, and so no ACK will be
>  >> sent even if there is an error.
>  >
>  > Good point.  I'll just casually remind you that I did say "untested" ;)
>  >
>  > I believe the following should work as intended (untested,
> cut-n-paste, etc.):
>  > .....
>
> I think ack must be set to NLM_F_ACK initially - otherwise auditd_set
> will always send the fast-tracked ACK even if the caller did not
> request one.

Another good point.  I think I'm working on too many different things
and forgetting the details between our emails :)  Sorry about that.

> The following is a concrete version of what I roughly
> suggested in the last email - is there a specific problem you see with
> the (ack || err) condition?

I'm happier with the bool over the integer type for the @ack variable.
I'd suggest updating the patch and posting it again so we can review
it in full, but we weren't very far off last time so I think it should
be close, if not acceptable on the next revision.

>  > I'm not sure I can recall everything from when I was thinking about
>  > this previously (that was about a week ago), but my quick thoughts
>  > right now are that you would need a lot more information and/or
>  > handshakes between the kernel and the daemon.
>  >
>  > Unfortunately, both the current audit design and implementation is
>  > seriously flawed in a number of areas.  One of these areas is the fact
>  > that data and control messages are sent using the same data flow.
>
> Makes sense. The question of why there isn't a separate control socket
> was one of the first we asked while looking into this.

Yeah, there is a lot I would have done differently, but that's the way
it goes sometimes.  I have plans to find some of the larger problems,
I just need to find some time to work on it.

-- 
paul-moore.com