netdev - Re: [PATCH] net: ipv6: Disable forwarding per interface via sysctl

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]

Date:   Fri, 16 Sep 2016 17:46:16 +0200
From:   Hannes Frederic Sowa <hannes@...essinduktion.org>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        Mike Manning <mmanning@...cade.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH] net: ipv6: Disable forwarding per interface via sysctl

On 16.09.2016 15:39, Eric Dumazet wrote:
> On Fri, 2016-09-16 at 13:47 +0100, Mike Manning wrote:
>> Disabling forwarding per interface via sysctl continues to allow
>> forwarding. This is contrary to the sysctl documentation stating that
>> the forwarding sysctl is per interface, whereas currently it is only
>> the sysctl for all interfaces that has an effect on forwarding. The
>> solution is to drop any received packets instead of forwarding them
>> if the ingress device has a per-device forwarding sysctl that is unset.
> 
> Some archaeological research might be needed because
> Documentation/networking/ip-sysctl.txt states :
> 
> IPv4 and IPv6 work differently here; e.g. netfilter must be used
> to control which interfaces may forward packets and which not.
> 
> If this netfilter requirement is obsolete, then your patch would need to
> change the doc as well.
> 
> Hannes can probably comment on this ?

Yep, thanks.

This commit breaks a very common setup: people globally enabled
forwarding but disabled the forwarding knob on one special interface to
allow this interface to participate in auto configuration from their
provider while still forwarding packets over this interface.

I fear this is so common that this would be a uapi violation.

Thanks,
Hannes