Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	David Ahern <dsa@cumulusnetworks.com>
Subject: [PATCH 0/6] stricter netlink validation
Date: Thu,  4 Apr 2019 08:54:02 +0200	[thread overview]
Message-ID: <20190404065408.5864-1-johannes@sipsolutions.net> (raw)

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



             reply	other threads:[~2019-04-04  6:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  6:54 Johannes Berg [this message]
2019-04-04  6:54 ` [PATCH 1/6] netlink: add NLA_MIN_LEN Johannes Berg
2019-04-04  6:54 ` [PATCH 2/6] netlink: make validation more configurable for future strictness Johannes Berg
2019-04-10 16:55   ` David Ahern
2019-04-12  9:43     ` Johannes Berg
2019-04-04  6:54 ` [PATCH 3/6] netlink: re-add parse/validate functions in strict mode Johannes Berg
2019-04-04  6:54 ` [PATCH 4/6] netlink: add strict parsing for future attributes Johannes Berg
2019-04-05 15:22   ` Nicolas Dichtel
2019-04-05 15:31     ` Johannes Berg
2019-04-05 15:40       ` Nicolas Dichtel
2019-04-04  6:54 ` [PATCH 5/6] genetlink: optionally validate strictly/dumps Johannes Berg
2019-04-04  6:54 ` [PATCH 6/6] nl80211: tag policies with strict_start_type Johannes Berg
2019-04-04 17:28 ` [PATCH 0/6] stricter netlink validation David Miller
2019-04-04 20:20   ` Johannes Berg
2019-04-05  2:44   ` David Ahern
2019-04-05  7:09     ` Johannes Berg
2019-04-05 11:47   ` Johannes Berg
2019-04-05 15:13     ` Johannes Berg
2019-04-08  9:00 ` Leon Romanovsky
2019-04-08  9:01   ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190404065408.5864-1-johannes@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox