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: <CAHC9VhSbOLR+yFbC6081UL87L2-SNV+gOBi2tD1YE7Th5hsGCw@mail.gmail.com>
Date: Fri, 29 Mar 2024 17:17:39 -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, 
	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 Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul@...l-moore.com> wrote:
>
> 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.

[Dropping alexey.kodanev@...cle.com due to email errors (unknown recipient)]

I'm looking at the possibility of doing the above and this is slowly
coming back to me as to why we haven't seriously tried this in the
past.  It's not as simple as calling one level down into a proto_ops
function table, the proto_ops function table would then need to jump
down into an associated proto function table.  Granted we aren't
talking per-packet overhead, but I can see this having a measurable
impact on connections/second benchmarks which likely isn't going to be
a welcome change.

-- 
paul-moore.com