Re: netlink ACK handling in audit_set_pid()
On Monday, November 13, 2023 9:43:07 AM EST Chris Riches wrote:
On Thursday, November 9, 2023 12:09:15 PM EST Steve Grubb wrote:
>> I was hoping some other people working on audit would step up.
>>
>> One idea I have not tested is to make a "command and control" fd that
>> would be used for enabling the audit system and setting the pid. This
>> would be separate from the data fd which processes events.
>
> Looks like we lost that ability a couple years ago when missing auditd
> detection was added. The fd that sets the pid is the one that gets all
> the events even if there is another fd available that belongs to the same
> pid.
Yes, I agree that a separate socket for control vs. messages would be
the best solution, and I briefly discussed this with the kernel
maintainer too. However, as you point out this is not possible today.
The root of the problem is the kernel flooding it's buffers when the ACK
option is given. It really should reserve space if that socket option is
active. I see Paul merged the patch, so that should work itself out
eventually.
I suppose the same thing can happen when auditd needs signal information. I
think the fix was generic enough to fix this use case also.
I think we should look at improving what we currently have in the
meantime - what do you think about the idea of tolerating ENOBUFS?
If we ignore this error, then I think there may be other problems because we
do not really know if the setup is correct. And what if we get ENOBUFS when
sending an audit event to the kernel? We have uncertainty that the event was
sent because under some requirements the application must exit if it can't
record who is doing something. (The code setting the pid and sending events
use the same core functions.)
-Steve