netdev - Re: [PATCH v2 0/5] strict netlink validation

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: <fbf176535c0553666aa7a7106452eb53734de790.camel@sipsolutions.net>
Date:   Sun, 28 Apr 2019 21:32:18 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     David Ahern <dsa@...ulusnetworks.com>, netdev@...r.kernel.org
Cc:     Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [PATCH v2 0/5] strict netlink validation

On Fri, 2019-04-26 at 20:28 -0600, David Ahern wrote:
> 
> I agree with this set and will help moving forward. As I recall it
> requires follow up patches for each policy to set strict_start_type
> opting in to the strict checking. With that in place new userspace on
> old kernels will get a failure trying to configure a feature the old
> kernel does not recognize.

Actually, that part you had already handled with nla_parse_strict() (now
nla_parse_strict_deprecated()) - and I'm not sure we can make this even
stricter because existing code might be setting future attributes
already, expecting them to be ignored. This is already fishy of
applications to expect though, but I'm not sure we really can change
that? I don't think I'm actually changing something here, but I'm
certainly open to suggestions - after all, when we actually do get
around to adding that future attribute it almost certainly will have a
different type than a (buggy) application would be using now.

However, what I did already do is that adding strict_start_type to
policies means that all future attributes added to those policies will
be handled in a strict fashion, i.e. if you add strict_start_type and
then add a new u32 attribute >= strict_start_type, that new u32
attribute will not be permitted to have a size other than 4 octets.

johannes