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

[Kuniyuki Iwashima <kuniyu@amazon.com>]

From: Lennart Poettering <lennart@poettering.net>
Date: Tue, 6 May 2025 14:17:22 +0200
> 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.

Note that this series is doing that, at sendmsg().


> 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.

Will add the socket option, and it will be enabled by default
to keep backward compatibility.

Thanks!