netdev - Re: [PATCH net-next v2] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <feef6da5-efbe-6ab9-0a2e-761cd7340cf7@gmail.com>
Date:   Wed, 28 Oct 2020 09:22:48 -0600
From:   David Ahern <dsahern@...il.com>
To:     Vincent Bernat <vincent@...nat.ch>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        Laurent Fasnacht <fasnacht@...tonmail.ch>
Subject: Re: [PATCH net-next v2] net: core: enable SO_BINDTODEVICE for
 non-root users

On 10/27/20 1:17 AM, Vincent Bernat wrote:
>  ❦ 23 octobre 2020 08:40 -06, David Ahern:
> 
>>> I am wondering if we should revert the patch for 5.10 while we can,
>>> waiting for a better solution (and breaking people relying on the new
>>> behavior in 5.9).
>>>
>>> Then, I can propose a patch with a sysctl to avoid breaking existing
>>> setups.
>>>
>>
>> I have not walked the details, but it seems like a security policy can
>> be installed to get the previous behavior.
> 
> libtorrent is using SO_BINDTODEVICE for some reason (code is quite old,
> so not git history). Previously, the call was unsuccesful and the error
> was logged and ignored. Now, it succeeds and circumvent the routing
> policy. Using Netfiler does not help as libtorrent won't act on dropped
> packets as the socket is already configured on the wrong interface.
> kprobe is unable to modify a syscall and seccomp cannot be applied
> globally. LSM are usually distro specific. What kind of security policy
> do you have in mind?
> 

nothing specific; I was hand waving.

There are bpf hooks to set and unset socket options, but those seem
inconvenient here.

I guess a sysctl is the only practical solution. If you do that we
should have granularity - any device, l3mdev devices only, ...