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]
Date:	Fri, 15 Oct 2010 16:23:57 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	netdev@...r.kernel.org, xemul@...nvz.org, kuznet@....inr.ac.ru,
	virtualization@...ts.linux-foundation.org
Subject: netlink versus pid namespaces

Hi,

I have been trying to figure out how pid namespaces interact
with netlink.

netlink uses pids (or really tids I hope?) to address sockets
associated with processes.

The netlink code passes around pids without caring much about 
the pid namespace.  It does pass around some information about the 
network namespace, but that doesn't help here because the pid
namespace is not necessarily related to the net namespace.

When the netlink consumer runs in kernel (like rtnetlink) and
happens to run in the same process context while receiving
and processing the data it should do the right thing because
it has the same pid namespace.

If it runs in some other process that is not guaranteed and
it may actually send the reply back to the wrong pid.

When a process receives netlink in user space and it isn't
in the same pid space as the sender it is unlikely that
the reply gets back.

Anything I'm missing here? 

Does netlink need to be extended? 
Or perhaps forbid passing netlink between name spaces?

Thanks,
-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ