netlink and user namespaces

netlink and user namespaces

[Alexander Larsson]

Now that I'm using a non-privileged user namespace for my desktop
sandboxing system all kind of network status things are breaking. The
reason for this is that they use netlink to enumerated interfaces, and
to verify that the replies are from the kernel (apparently anyone can
send anyone netlink messages) this code is verifying that the
SCM_CREDENTIAL sender of the netlink messages is uid 0.

For instance: 
http://git.0pointer.net/avahi.git/commit/avahi-core/netlink.c?id=37b2be93e63ceff95698f24cd91cb11774eb621c
and:
https://git.gnome.org/browse/glib/tree/gio/gnetworkmonitornetlink.c#n340

This obviously breaks when uid is not mapped (as it can't be in an
unprivileged user namespace), as uid will be overflowuid.

Is there any other way to check that a netlink message is from the
kernel?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org            alexander.larsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 
He's an uncontrollable skateboarding farmboy trapped in a world he never 
made. She's a strong-willed renegade schoolgirl married to the Mob. They 
fight crime! 

Re: netlink and user namespaces

[Eric W. Biederman]

Alexander Larsson <alexl@redhat.com> writes:

> Now that I'm using a non-privileged user namespace for my desktop
> sandboxing system all kind of network status things are breaking. The
> reason for this is that they use netlink to enumerated interfaces, and
> to verify that the replies are from the kernel (apparently anyone can
> send anyone netlink messages) this code is verifying that the
> SCM_CREDENTIAL sender of the netlink messages is uid 0.
>
> For instance: 
> http://git.0pointer.net/avahi.git/commit/avahi-core/netlink.c?id=37b2be93e63ceff95698f24cd91cb11774eb621c
> and:
> https://git.gnome.org/browse/glib/tree/gio/gnetworkmonitornetlink.c#n340
>
> This obviously breaks when uid is not mapped (as it can't be in an
> unprivileged user namespace), as uid will be overflowuid.
>
> Is there any other way to check that a netlink message is from the
> kernel?

*scratches my head*  Those are weird pieces of code.

The answer is the way you do this with any other socket.

Call recvfrom or recvmsg.
Looking at the senders address.
If in the senders address nl_pid == 0 then the message is from
the kernel.  Otherwise the message is from userspace.

Looking anywhere else at anything else is bogus.

And a note.  nl_pid is short for netlink port id.  It is not a process id.

Eric

Re: netlink and user namespaces

[Eric W. Biederman]

Alexander Larsson <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:

> Now that I'm using a non-privileged user namespace for my desktop
> sandboxing system all kind of network status things are breaking. The
> reason for this is that they use netlink to enumerated interfaces, and
> to verify that the replies are from the kernel (apparently anyone can
> send anyone netlink messages) this code is verifying that the
> SCM_CREDENTIAL sender of the netlink messages is uid 0.
>
> For instance: 
> http://git.0pointer.net/avahi.git/commit/avahi-core/netlink.c?id=37b2be93e63ceff95698f24cd91cb11774eb621c
> and:
> https://git.gnome.org/browse/glib/tree/gio/gnetworkmonitornetlink.c#n340
>
> This obviously breaks when uid is not mapped (as it can't be in an
> unprivileged user namespace), as uid will be overflowuid.
>
> Is there any other way to check that a netlink message is from the
> kernel?

*scratches my head*  Those are weird pieces of code.

The answer is the way you do this with any other socket.

Call recvfrom or recvmsg.
Looking at the senders address.
If in the senders address nl_pid == 0 then the message is from
the kernel.  Otherwise the message is from userspace.

Looking anywhere else at anything else is bogus.

And a note.  nl_pid is short for netlink port id.  It is not a process id.

Eric