netdev - Re: [PATCH RFC v2 net-next 03/25] netlink: introduce NLM_F_DUMP_PROPER

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:20:08 -0600
From:   David Ahern <dsahern@...il.com>
To:     Jiri Benc <jbenc@...hat.com>
Cc:     Christian Brauner <christian@...uner.io>, netdev@...r.kernel.org,
        davem@...emloft.net, stephen@...workplumber.org
Subject: Re: [PATCH RFC v2 net-next 03/25] netlink: introduce
 NLM_F_DUMP_PROPER_HDR flag

On 10/2/18 10:30 AM, Jiri Benc wrote:
> On Tue, 2 Oct 2018 08:57:24 -0600, David Ahern wrote:
>> You can when you introduce a new option or a new flag that is required
>> to get new behavior like kernel side filtering.
> 
> Yes. That was what I tried with the patchset a few years back. It would
> be nice to revive the effort.
> 
>> I chose a netlink flag for consistency with NLM_F_DUMP_INTR and
>> NLM_F_DUMP_FILTERED. Both are netlink flags. This patch set fixes only
>> what is broken -- dumps.
> 
> When we're introducing better input checking in netlink (which is a
> good thing!), it would be good to do it consistently and have it
> generic across all operations.
> 

Thinking about this some more... a setsockopt to enable the new checks
would provide a definitive way for userspace to know if the feature is
supported or not.

As for expanding the scope to NEW (and maybe DEL) commands (which was
the point of your patch set 3 years ago), I think is an idealistic goal
that is not practical to implement. Trying to go through all commands
and cover all options and valid combinations to report back errors is a
herculean effort with little return on the time investment. New commands
and new features should certainly add rigid checks for valid
combinations, but a retrospective audit on existing commands is a time
sink. Perhaps new attributes can be checked (new command on old kernel);
seems like that can be covered by a simple change to nla_parse to handle
type > maxtype based on a new input flag.

Once the flag goes in, all of the commands to be affected by it have to
be done in the same release. I have done that for the dump commands
which is fairly easy considering the existing code.