netlink scm creds uid and gids are always 0.

While working on the kuid_t and kgid_t conversion of the audit subsystem I noticed that since the performance problem of scm creds and af_unix sockets were fixed af_netlink sockets have not filled in the uid or gid of the originator of the socket.

I think all we need is an appropriate cred_to_ucred call to fix this regression, but I am going so many different directions right now I can't get myself to focus on this long enough to work up an appripriate patch to fix.

Eric do you think you might take a gander?

The commit where this regression was introduced appears to be.

commit 16e5726269611b71c930054ffe9b858c1cea88eb

Author: Eric Dumazet <[email protected]>
Date:   Mon Sep 19 05:52:27 2011 +0000

af_unix: dont send SCM_CREDENTIALS by default

Since commit 7361c36c5224 (af_unix: Allow credentials to work across user and pid namespaces) af_unix performance dropped a lot.

This is because we now take a reference on pid and cred in each write(), and release them in read(), usually done from another process, eventually from another cpu. This triggers false sharing.

Wasnt it fixed by e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea

af_netlink: force credentials passing [CVE-2012-3520]

Or is it a different thing ?

Same thing. I didn't see that fix go by.

One more little thing I can cross off my list. Hooray!

Eric

Looking a little deeper it looks like I am going to have to give scm credentials a little more tender loving care.

There is still a possible issue with netlink sockets and pids when the two processes talking over netlink are in different pid namespaces.

And I need to take care in my usernamespace tree for 3.7, to keep from reintroucing the ability to spoof root if the two netlink talkers are in different user namespaces.

With a little luck for uids and gids I can just pass around kuid_t and kgid_t values and throw out the ref-counting complexity. Something to sleep on and benchmark, and then generate a patch I guess.

I know at least from my last attempt that ref counting in the NETLINK_CB was a lost cause. So I don't know what to do about the pids :(

Eric

Isn't there a more general problem of the sending process exiting and its pid being reused before the receiving program makes use of the value?

IIRC 2.6.27 tried to alleviate this for some code paths by using a reference-counted structure for some kernel calls. (A PITA because the function to lose the reference is exported GPL_ONLY ...)

David