netdev - Re: [RFC PATCH net-next v1] net: core: enable SO

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

Message-ID: <m3eets9zaz.fsf@bernat.ch>
Date:   Mon, 16 Mar 2020 14:58:28 +0100
From:   Vincent Bernat <vincent@...nat.ch>
To:     David Miller <davem@...emloft.net>
Cc:     dsahern@...il.com, netdev@...r.kernel.org, kuba@...nel.org,
        edumazet@...gle.com, kafai@...com
Subject: Re: [RFC PATCH net-next v1] net: core: enable SO_BINDTODEVICE for non-root users

 ❦ 16 mars 2020 02:13 -07, David Miller:

>> As a reminder, there are currently 3 APIs to specify a preferred device
>> association which influences route lookups:
>> 
>> 1. SO_BINDTODEVICE - sets sk_bound_dev_if and is the strongest binding
>> (ie., can not be overridden),
>> 
>> 2. IP_UNICAST_IF / IPV6_UNICAST_IF - sets uc_index / ucast_oif and is
>> sticky for a socket, and
>> 
>> 3. IP_PKTINFO / IPV6_PKTINFO - which is per message.
>> 
>> The first, SO_BINDTODEVICE, requires root privileges. The last 2 do not
>> require root privileges but only apply to raw and UDP sockets making TCP
>> the outlier.
>> 
>> Further, a downside to the last 2 is that they work for sendmsg only;
>> there is no way to definitively match a response to the sending socket.
>> The key point is that UDP and raw have multiple non-root APIs to dictate
>> a preferred device for sending messages.
>> 
>> Vincent's patch simplifies things quite a bit - allowing consistency
>> across the protocols and directions - but without overriding any
>> administrator settings (e.g., inherited bindings via ebpf programs).
>
> Understood, but I still wonder if this mis-match of privilege
> requirements was by design or unintentional.
>
> Allowing arbitrary users to specify SO_BINDTODEVICE has broad and far
> reaching consequences, so at a minimum if we are going to remove the
> restriction we should at least discuss the implications.

Without VRF, it's hard to build a case where a process could "evade" its
setup using SO_BINDTODEVICE. It could be used to use alternative routing
table when ip rules are using interfaces (which is not uncommon), but I
think almost all such setups are using this to have some isolation in
routing (not for local processes), something that could be replaced by
VRF.

With VRF, removing the restriction allows a process to have more
possibilities than previously if it has not been restricted. This is my
use case: it is actually difficult to use VRF for anything else than
routing because local processes may want to receive connections in a VRF
and forward them to another one.

In summary, unless I am missing something, the main implication is when
using VRF. Without VRF, no real change.

An alternative would be to use a sysctl to decide the behaviour.
-- 
Man is the only animal that blushes -- or needs to.
		-- Mark Twain