netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC v3 0/6] netlink strict validation
@ 2019-03-25  9:09 Johannes Berg
  2019-03-25  9:10 ` [RFC v3 1/6] netlink: add NLA_MIN_LEN Johannes Berg
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Johannes Berg @ 2019-03-25  9:09 UTC (permalink / raw)
  To: netdev; +Cc: David Ahern, Pablo Neira Ayuso

Here's yet another respin. The big change since v2 is replacing the 2nd
patch by one that actually makes each validation bit configurable. The
old "strict" mode ends up setting 2 of the 5 bits, the new default (and
very strict) mode ends up with all 5 bits, of course.

This was inspired by a side discussion with Pablo, who still thinks that
accepting unknown attributes is a good thing. I obviously disagree, as
such attributes might modify behaviour and thus the user intent is no
longer guaranteed when ignored, but there are some rare cases where it
may be acceptable (such as a power-saving filter), though even in those
it's probably better to let the user know.

Anyway, inspired by that discussion I split out the NL_VALIDATE_UNSPEC
as that might actually be useful for even *old* code, seeing how you can
fill in all the policies, using NLA_MIN_LEN instead of NLA_UNSPEC for all
existing attributes, and then new attributes are forced to have a policy.

This is really the only change, but in order to do it users still need to
use the __nlmsg_parse(), __nla_parse() (and other double-underscore)
versions of the functions.

If Pablo (and Jamal to some extent, I think) end up convincing us that
the liberal validation is actually desired (sometimes), it may make some
sense to rename the *_deprecated() functions to something less shouting,
perhaps use *_old(). I just think that the default nla_parse() should be
defaulting to the stricter behaviour, and most people agree that the
default behaviour is desirable.

FWIW, Pablo also more or less agrees, but would like to have query
capabilities in the kernel first, so his userspace can figure out what
would be accepted w/o going to a "try this, remove if fails" dance.
I'll take a look at his old "netlink bus descriptions" patch to see
if that matches what I want to do wrt. this and see how we can merge
the two approaches.

johannes



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-03-25  9:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-25  9:09 [RFC v3 0/6] netlink strict validation Johannes Berg
2019-03-25  9:10 ` [RFC v3 1/6] netlink: add NLA_MIN_LEN Johannes Berg
2019-03-25  9:10 ` [RFC v3 2/6] netlink: make validation more configurable for future strictness Johannes Berg
2019-03-25  9:10 ` [RFC v3 3/6] netlink: re-add parse/validate functions in strict mode Johannes Berg
2019-03-25  9:10 ` [RFC v3 4/6] netlink: add strict parsing for future attributes Johannes Berg
2019-03-25  9:10 ` [RFC v3 5/6] genetlink: optionally validate strictly/dumps Johannes Berg
2019-03-25  9:10 ` [RFC v3 6/6] nl80211: tag policies with strict_start_type Johannes Berg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).