[PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Paul Moore]

On Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
> <ivanov.mikhail1 at huawei-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 at oracle.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