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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 2 Oct 2018 13:06:14 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     David Ahern <dsahern@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, christian@...uner.io,
        stephen@...workplumber.org, David Ahern <dsahern@...il.com>
Subject: Re: [PATCH RFC v2 net-next 03/25] netlink: introduce
 NLM_F_DUMP_PROPER_HDR flag

On Mon,  1 Oct 2018 17:28:29 -0700, David Ahern wrote:
> Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
> kernel that it believes it is sending the right header struct for the
> dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).

Why is this limited to dumps? Other kind of netlink messages contain
the common struct, too. When introducing such mechanism, please make it
generic.

Last time when we were discussing strict checking in netlink, it was
suggested to add a socket option instead of adding NLM flags[1].
It makes a lot of sense: the number of flags is very limited and we'd
run out of them pretty fast. It's not just the header structure that
is currently checked sloppily. It's also attributes, flags in
attributes, etc. We can't assign a flag to all of them.

You should also consider a different name for the flag: it should
reflect what the effect of the flag is. "Proper header" is not an
effect, it's a requirement for the message to pass. The effect is
enforced strict checking of the header.

 Jiri

[1] https://marc.info/?l=linux-netdev&m=144492718118955

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ