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

[Paul Moore]

On Mon, May 5, 2025 at 8:35 PM Kuniyuki Iwashima <kuniyu at amazon.com> wrote:
> From: Paul Moore <paul at paul-moore.com>
> Date: Mon, 5 May 2025 19:21:25 -0400
> > On Mon, May 5, 2025 at 5:58 PM Kuniyuki Iwashima <kuniyu at 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.
> >
> > I'll take a closer look later this week, but generally speaking LSM
> > hooks are intended for observability and access control, not data
> > modification, which means what you are trying to accomplish may not be
> > a good fit for a LSM hook.  Have you considered simply inspecting the
> > skb at sendmsg() and rejecting the send in the LSM hook if a
> > SCM_RIGHTS cmsg is present that doesn't fit within the security policy
> > implemented in your BPF program?
>
> I think the simple inspection (accept all or deny) does not cover
> a real use case and is not that helpful.
>
> I don't like to add another hook point in AF_UNIX code just because
> of it and rather want to reuse the exisiting hook as we have a nice
> place.

Reading quickly through the other replies, I'm guessing you are going
to be moving away from the LSM scrubbing proposed here (which I
believe is a good idea), so I won't bother you with more feedback
here.  However, if for some reason you still decide that you want to
pursue the LSM scrubbing approach please let me know so we can discuss
this further (on-list).

> Also, passing skb makes it possible to build much more flexible
> policy as it allows bpf prog to inspect the skb payload with
> existing bpf helpers.

-- 
paul-moore.com