netdev - Re: [RFC PATCH net-next 0/9] netlink: strict attribute checking option

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]

Message-Id: <20151018.192945.1549146309693737023.davem@davemloft.net>
Date:	Sun, 18 Oct 2015 19:29:45 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dsa@...ulusnetworks.com
Cc:	jbenc@...hat.com, netdev@...r.kernel.org, tgraf@...g.ch
Subject: Re: [RFC PATCH net-next 0/9] netlink: strict attribute checking
 option

From: David Ahern <dsa@...ulusnetworks.com>
Date: Fri, 16 Oct 2015 09:57:33 -0600

> On 10/16/15 2:02 AM, Jiri Benc wrote:
>> On Fri, 16 Oct 2015 01:06:44 -0700 (PDT), David Miller wrote:
>>> No, it's definitely not OK, because lwtunnel support exists in
>>> Linus's tree.
>>>
>>> And tools should be able to work on all kernels where lwtunnel support
>>> is available.
>>
>> You can consider the lwtunnels feature as not finished in the current
>> Linus's tree. It works, it won't change (thus anything using it in its
>> current form will continue to work in all the future kernels), but
>> mainstream tools won't make use of it until a kernel version later
>> which will get some additional support.
>>
>> I don't think it's much of a problem and I don't think it is the first
>> time this would happen.
>>
>> I'm afraid I don't have any solution that could do better.
> 
> What about a flag that requests the version from the relevant kernel
> subsystem?

The whole point of having an easily extensible protocol like netlink
with attributes and whatnot was to avoid messy schemes like
versioning.

The big mistake was ignoring unknown attributes.  I mean seriously,
think about it, what if the new attribute specified by the user was
some security setting or something?  I'm sure even more dangerous
examples can be imagined.

I'm beginning to wonder if we can just change this unilaterally to
not ignore unrecognized attributes.

I am increasingly certain that things that would "break" we wouldn't
want to succeed anyways.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html