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  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:   Sun, 28 Apr 2019 21:32:18 +0200
From:   Johannes Berg <>
To:     David Ahern <>,
Cc:     Pablo Neira Ayuso <>
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.


Powered by blists - more mailing lists