Message-ID: <47DAB065.6060804@openvz.org>
Date: Fri, 14 Mar 2008 20:05:41 +0300
From: Pavel Emelyanov <xemul@openvz.org>
User-Agent: Thunderbird 2.0.0.12 (X11/20080213)
MIME-Version: 1.0
To: Thomas Graf <tgraf@suug.ch>
CC: David Woodhouse <dwmw2@infradead.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: Audit vs netlink interaction problem
References: <47DAA660.90401@openvz.org> <20080314163929.GP20815@postel.suug.ch>
In-Reply-To: <20080314163929.GP20815@postel.suug.ch>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2537
Lines: 56

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/