Re: [PATCH v1 bpf-next 0/5] af_unix: Allow BPF LSM to scrub SCM_RIGHTS at sendmsg().

[Lennart Poettering <lennart@poettering.net>]

On Mo, 05.05.25 14:56, Kuniyuki Iwashima (kuniyu@amazon.com) wrote:

> As long as recvmsg() or recvmmsg() is used with cmsg, it is not
> possible to avoid receiving file descriptors via SCM_RIGHTS.
>
> This behaviour has occasionally been flagged as problematic.
>
> For instance, as noted on the uAPI Group page [0], an untrusted peer
> could send a file descriptor pointing to a hung NFS mount and then
> close it.  Once the receiver calls recvmsg() with msg_control, the
> descriptor is automatically installed, and then the responsibility
> for the final close() now falls on the receiver, which may result
> in blocking the process for a long time.
>
> systemd calls cmsg_close_all() [1] after each recvmsg() to close()
> unwanted file descriptors sent via SCM_RIGHTS.
>
> However, this cannot work around the issue because the last fput()
> could occur on the receiver side once sendmsg() with SCM_RIGHTS
> succeeds.  Also, even filtering by LSM at recvmsg() does not work
> for the same reason.
>
> Thus, we need a better way to filter SCM_RIGHTS on the sender side.
>
> This series allows BPF LSM to inspect skb at sendmsg() and scrub
> SCM_RIGHTS fds by kfunc.

Frankly, this sounds like a bad idea to me. The number and order of
the fds passed matters, and if you magically make some fds disappear
everything becomes a complete mess for most protocols. Hence, making
fds disappear from a messasge mid-flight is really not a realistic
option, already for compat. Not for systemd, and not for other tools
either I am sure.

I also think it's pointless to enforce this on the receiving side,
because the deed is done by then. i.e. it doesn't matter if we have to
close the fd via bpf or in userspace, we still have to wait for it to
be closed on the receiving side, hence we have to pay. i.e. focus must
be to refuse the fds on the sender side, instead of allowing this to
go to the receiver side.

From my perspective this must be enforced on sender side. And more
importantly, for systemd's usecase it would be a lot more relevant to
have a simple, dumb boolean per socket instead of the full bpf
machinery. I mean, as much as I like the lsm-bpf concept it's not
clear to me that this is the right place to make use of it. I
personally would really like to see a SO_PASSRIGHTS sockopt, that is
modelled after SO_PASSCREDS and SO_PASSSEC.

Lennart

--
Lennart Poettering, Berlin