linux-kernel - Audit vs netlink interaction problem

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-next>] [day] [month] [year] [list]

Message-ID: <47DAA660.90401@openvz.org>
Date:	Fri, 14 Mar 2008 19:22:56 +0300
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	David Woodhouse <dwmw2@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Audit vs netlink interaction problem

Hi, David!

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 reason I raised this problem is that I'm now working on pid 
and network namespaces and found, that this problem doesn't
allow to resolve the following issue gracefully.

The task_struct->tgid field, which is currently used in netlink
for auto-binding, is going to be deprecated. Thus I have to make 
netlink auto-binding play another rules when selecting a pid, 
but this will break the audit work for sure, since it implicitly 
relies, that the netlink socket will be bound to the current 
task pid.

What do you think about it?

Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/