netlink scm creds uid and gids are always 0.

netlink scm creds uid and gids are always 0.

[Eric W. Biederman]

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 <eric.dumazet@gmail.com>
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.
    

Re: netlink scm creds uid and gids are always 0.

[Eric Dumazet]

On Thu, 2012-08-23 at 23:45 -0700, Eric W. Biederman wrote:
> 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?

Wasnt it fixed by e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea

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

Or is it a different thing ?

Re: netlink scm creds uid and gids are always 0.

[Eric W. Biederman]

Eric Dumazet <eric.dumazet@gmail.com> writes:

> On Thu, 2012-08-23 at 23:45 -0700, Eric W. Biederman wrote:
>> 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?
>
> 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

Re: netlink scm creds uid and gids are always 0.

[Eric W. Biederman]

ebiederm@xmission.com (Eric W. Biederman) writes:

> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
>> On Thu, 2012-08-23 at 23:45 -0700, Eric W. Biederman wrote:
>>> 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?
>>
>> 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!

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

RE: netlink scm creds uid and gids are always 0.

[David Laight]

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

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