netdev - [PATCH 0/6] stricter 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-next>] [day] [month] [year] [list]

Date:   Thu,  4 Apr 2019 08:54:02 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        David Ahern <dsa@...ulusnetworks.com>
Subject: [PATCH 0/6] stricter netlink validation

Here's a version that has passed build testing ;-)

As mentioned in the RFC postings, this was inspired by talks
between David, Pablo and myself. Pablo is somewhat firmly on
the side of less strict validation, while David and myself
are in the very strict validation camp. If I understand him
correctly, Pablo doesn't mind the strict validation if it is
accompanied by exposing the policy to userspace, but that
isn't something we can do today. I'll work on it later.

What this series does is basically first replace nla_parse()
and all its friends by nla_parse_deprecated(), while making
all of those just inlines around __nla_parse() and friends
with configurable strict checking bits. Three versions exist
after this patchset:
 * liberal           - no bits set
 * deprecated_strict - reject attrs > maxtype
                       reject trailing junk
 * new default       - reject trailing junk
                       reject attrs > maxtype
                       reject policy entries that are NLA_UNSPEC
                       require a policy
                       strictly validate attributes

The NLA_UNSPEC one can be opted in even in existing code with
existing userspace in the future, as policies are updated.

In addition, infrastructure is added to opt in to the strict
attribute validation even for new attributes added to existing
policies, regardless of the nla_parse() strictness setting
described above, as new attributes should not be a compatibility
issue.

Finally, much of this is plumbed through generic netlink etc.,
and I've included a patch to tag nl80211 with the future attribute
strictness for reference.

johannes