Re: Audit vs netlink interaction problem

[Pavel Emelyanov <xemul@openvz.org>]

Thomas Graf wrote:
> * Pavel Emelyanov <xemul@openvz.org> 2008-03-14 19:22
>> I've found an interesting feature of how audit uses netlink for
>> communications. Look.
>>
>> The kauditd_thread() calls netlink_unicast() and passes the 
>> audit_pid to it. The audit_pid, in turn, is received from the 
>> user space and the tool (I've checked the audit v1.6.9) uses 
>> getpid() to pass one in the kernel. Besides, this tool doesn't
>> bind the netlink socket to this id, but simply creates it 
>> allowing the kernel to auto-bind one.
>>
>> That's the preamble.
>>
>> The problem is that netlink_autobind() _does_not_ guarantees
>> that the socket will be auto-binded to the current pid. Instead
>> it uses the current pid as a hint to start looking for a free
>> id. So, in case of conflict, the audit messages can be sent
>> to a wrong socket. This can happen (it's unlikely, but can be)
>> in case some task opens more than one netlink sockets and then
>> the audit one starts - in this case the audit's pid can be busy
>> and its socket will be bound to another id.
> 
> The audit userspace tool should be fixed, no question. It can continue

Oh, this is good.
I was afraid, that we'd have to stick to this logic...

> to auto bind but must report the correct netlink pid.

Hmmm... I'm afraid, that this can break the audit filtering and signal
auditing. I haven't yet looked deep into it, but it compares the 
task->tgid with this audit_pid for different purposes. If audit_pid
changes this code will be broken.

That's why I asked David for comments.

> As a workaround: Assuming that the audit daemon is the only application
> to issue a AUDIT_SET command to set the status pid, the kernel can
> compare the netlink source pid of the AUDIT_SET message and compare it

Bu we have no the netlink socket at the moment of setting the pid to
check this. The audit_reveive_msg() call which does this set is received 
via another (pre-created global) socket.

> against the status pid provided. If they differ, issue a warning but
> use the netlink source pid thus covering the case where the auto bound
> netlink pid actually differs from the process pid.

I though, that proper behavior would be to split audit_pid, used for
filtering from the audit_nlk_pid used for netlink communications.