netdev - Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket

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]

Message-ID: <CAHC9VhRN4deUerWtxxGypFH1o+NRD=Z+U96H2qB0xv+0d6ekEA@mail.gmail.com>
Date: Fri, 29 Mar 2024 16:07:17 -0400
From: Paul Moore <paul@...l-moore.com>
To: Ivanov Mikhail <ivanov.mikhail1@...wei-partners.com>
Cc: Mickaël Salaün <mic@...ikod.net>, 
	linux-security-module@...r.kernel.org, netdev@...r.kernel.org, 
	Alexey Kodanev <alexey.kodanev@...cle.com>, Eric Dumazet <edumazet@...gle.com>, 
	Günther Noack <gnoack@...gle.com>, 
	Konstantin Meskhidze <konstantin.meskhidze@...wei.com>, 
	Muhammad Usama Anjum <usama.anjum@...labora.com>, "Serge E . Hallyn" <serge@...lyn.com>, 
	yusongping <yusongping@...wei.com>, artem.kuzin@...wei.com
Subject: Re: [PATCH v1 1/2] lsm: Check and handle error priority for
 socket_bind and socket_connect

On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
<ivanov.mikhail1@...wei-partners.com> wrote:
> On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > Because the security_socket_bind and the security_socket_bind hooks are
> > called before the network stack, it is easy to introduce error code
> > inconsistencies. Instead of adding new checks to current and future
> > LSMs, let's fix the related hook instead. The new checks are already
> > (partially) implemented by SELinux and Landlock, and it should not
> > change user space behavior but improve error code consistency instead.
>
> It would probably be better to allow the network stack to perform such
> checks before calling LSM hooks. This may lead to following improvements:

...

> This may result in adding new method to socket->ops.

I don't think there is a "may result" here, it will *require* a new
socket::proto_ops function (addr_validate?).  If you want to pursue
this with the netdev folks to see if they would be willing to adopt
such an approach I think that would be a great idea.  Just be warned,
there have been difficulties in the past when trying to get any sort
of LSM accommodations from the netdev folks.

-- 
paul-moore.com