linux-kernel - Re: [PATCH] drivers: connector: cn_proc: allow limiting certain messages

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:   Mon, 17 Feb 2020 18:52:35 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     danielwa@...co.com
Cc:     zbr@...emap.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers: connector: cn_proc: allow limiting certain
 messages

From: "Daniel Walker (danielwa)" <danielwa@...co.com>
Date: Mon, 17 Feb 2020 17:52:11 +0000

> On Mon, Feb 17, 2020 at 08:44:35PM +0300, Evgeniy Polyakov wrote:
>>    Hi Daniel, David
>>     
>>    17.02.2020, 20:26, "Daniel Walker (danielwa)" <danielwa@...co.com>:
>>    > On Sun, Feb 16, 2020 at 06:44:43PM -0800, David Miller wrote:
>>    >>  This is a netlink based facility, therefore please you should add
>>    filtering
>>    >>  capabilities to the netlink configuration and communications path.
>>    >>
>>    >>  Module parameters are quite verboten.
>>    >
>>    > How about adding in Kconfig options to limit the types of messages? The
>>    issue
>>    > with this interface is that it's very easy for someone to enable the
>>    interface
>>    > as a listener, then never turn the interface off. Then it becomes a
>>    broadcast
>>    > interface. It's desirable to limit the more noisy messages in some
>>    cases.
>>     
>>     
>>    Compile-time options are binary switches which live forever after kernel
>>    config has been created, its not gonna help those who enabled messages.
>>    Kernel modules are kind of no-go, since it requires reboot to change in
>>    some cases.
>>     
>>    Having netlink control from userspace is a nice option, and connector has
>>    simple userspace->kernelspace channel,
>>    but it requires additional userspace utils or programming, which is still
>>    cumbersome.
>>     
>>    What about sysfs interface with one file per message type?
> 
> You mean similar to the module parameters I've done, but thru sysfs ? It would
> work for Cisco. I kind of like Kconfig because it also reduces kernel size for
> messages you may never want to see.

Even the sysfs has major downsides, as it fails to take the socket context into
consideration and makes a system wide decision for what should be a per service
decision.