Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: David Miller <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	pablo@netfilter.org, dsa@cumulusnetworks.com
Subject: Re: [PATCH 0/6] stricter netlink validation
Date: Fri, 05 Apr 2019 17:13:48 +0200	[thread overview]
Message-ID: <9371ebeec2af95a8884feab23dbb0b932d7cf9ce.camel@sipsolutions.net> (raw)
In-Reply-To: <d423d283c91a48f75a509ee74255327cfe92fe97.camel@sipsolutions.net>

On Fri, 2019-04-05 at 13:47 +0200, Johannes Berg wrote:
> 
> I've also pushed some very much WIP code to the netlink-policy-export
> branch there that exposes the policies to userspace, there at least for
> generic netlink now.

Seems to more or less work now, userspace gets things like (for
nl80211):

(ID 0x18 is the nl80211 genl family)

	ID: 0x18  policy[0]:attr[1]: type=U32
[...]
	ID: 0x18  policy[0]:attr[87]: type=U32
	ID: 0x18  policy[0]:attr[88]: type=U64
	ID: 0x18  policy[0]:attr[89]: type=U8
	ID: 0x18  policy[0]:attr[90]: type=NESTED
	ID: 0x18  policy[0]:attr[91]: type=BINARY
[...]
	ID: 0x18  policy[0]:attr[270]: type=NESTED policy:1
[...]
	ID: 0x18  policy[0]:attr[273]: type=NESTED policy:2
[...]
	ID: 0x18  policy[1]:attr[1]: type=FLAG
	ID: 0x18  policy[1]:attr[2]: type=BINARY
	ID: 0x18  policy[1]:attr[3]: type=BINARY
[...]
	ID: 0x18  policy[2]:attr[1]: type=REJECT
	ID: 0x18  policy[2]:attr[2]: type=REJECT
	ID: 0x18  policy[2]:attr[3]: type=REJECT
	ID: 0x18  policy[2]:attr[4]: type=REJECT
	ID: 0x18  policy[2]:attr[5]: type=NESTED_ARRAY policy:3
[...]
	ID: 0x18  policy[3]:attr[3]: type=NESTED policy:4

etc.

See net/wireless/nl80211.c nl80211_policy[] for the original data, it's
unchanged over current net-next.


Policy 0 is - by convention - the top-level policy, but once I fix the
recursion issue in validate_nla() it's possible that a nested attribute
refers back to the top-level policy.

There are some bugs, like it generating an almost-empty message for when
the type is NLA_UNSPEC rather than eliding it entirely, and I haven't
implemented a bunch of things yet:

                /* TODO advertise range (min/max) */
                /* TODO advertise min/max len */
                /* TODO show reject string if any */

Also, I haven't hooked it up to anything that's not generic netlink, but
the API should be general enough for anyone:

int netlink_policy_dump_start(const struct nla_policy *policy,
                              unsigned int maxtype,
                              unsigned long *state);
bool netlink_policy_dump_loop(unsigned long *state);
int netlink_policy_dump_write(struct sk_buff *skb, unsigned long state);

(*state/state is &cb->args[n]/cb->args[n] for the netlink dump, it will
generate one message per type. That may be overkill, but it lets us
include the potentially long reject string etc. without worrying about
any message size limitations.)

It feels like it's working, and so I'd like to propose formal patches
soon.

Pablo, what do you think? It seems to me that this type of thing would
address most if not all what you did with the object/bus description
stuff, while not writing any new code, the info is taken straight from
the policy.

johannes


  reply	other threads:[~2019-04-05 15:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  6:54 [PATCH 0/6] stricter netlink validation Johannes Berg
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 [this message]
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=9371ebeec2af95a8884feab23dbb0b932d7cf9ce.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=davem@davemloft.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