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]
Message-ID: <CAHC9VhQBV1mcFUmXQs1-VKpAVdaAQ3EiGk-G3ybxfcBkoKGwcw@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ