netdev - Re: [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid checking of data in dump request

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

Date:   Wed, 3 Oct 2018 09:21:15 -0600
From:   David Ahern <dsahern@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        David Ahern <dsahern@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, christian@...uner.io,
        jbenc@...hat.com
Subject: Re: [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid
 checking of data in dump request

On 10/3/18 8:59 AM, Stephen Hemminger wrote:
> On Mon,  1 Oct 2018 17:28:26 -0700
> David Ahern <dsahern@...nel.org> wrote:
> 
>> How to resolve the problem of not breaking old userspace yet be able to
>> move forward with new features such as kernel side filtering which are
>> crucial for efficient operation at high scale?
> 
> What about forward compatibility? How would this work when running new iproute2
> command on older kernels?
> 
> I expect the new command would set the "I am smart flag" and the older
> kernel would ignore it. The if the header for the message type had
> changed, the dump would be broken.
> 

The kernel today happily ignores garbage in the request it does not
understand. If the new iproute2 sends a dump request with attributes or
fields in the header set the kernel ignores it.

With the setsockopt option for setting the flag, userspace knows the
kernel does not support attribute checking and kernel side filtering.

As far as changing the header (new iproute2 on old kernel), there are 3
dumps that look at the header beyond the family:
1. link dumps - but it has the expected ifinfomsg header

2. neighbor dumps (expects the right ndmsg header)

3. fdb dumps - wrongly expect ifinfomsg header but there is patch to
detect when the ndmsg header is sent (ip neigh vs bridge fdb)

The 4th dump that looks at the header is addresses. Those patches were
added in this development cycle. Those dumps need to be wrapped in the
'userspace has a clue' setting or reverted until this is figured out.