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

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

[Kuniyuki Iwashima]

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.

Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]


Kuniyuki Iwashima (5):
  af_unix: Call security_unix_may_send() in sendmsg() for all socket
    types
  af_unix: Pass skb to security_unix_may_send().
  af_unix: Remove redundant scm->fp check in __scm_destroy().
  bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().
  selftest: bpf: Add test for bpf_unix_scrub_fds().

 include/linux/lsm_hook_defs.h                 |   3 +-
 include/linux/security.h                      |   5 +-
 include/net/af_unix.h                         |   1 +
 include/net/scm.h                             |   5 +-
 net/compat.c                                  |   2 +-
 net/core/filter.c                             |  19 ++-
 net/core/scm.c                                |  19 +--
 net/unix/af_unix.c                            |  48 ++++--
 security/landlock/task.c                      |   6 +-
 security/security.c                           |   5 +-
 security/selinux/hooks.c                      |   6 +-
 security/smack/smack_lsm.c                    |   6 +-
 .../bpf/prog_tests/lsm_unix_may_send.c        | 160 ++++++++++++++++++
 .../selftests/bpf/progs/lsm_unix_may_send.c   |  30 ++++
 14 files changed, 282 insertions(+), 33 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_unix_may_send.c
 create mode 100644 tools/testing/selftests/bpf/progs/lsm_unix_may_send.c

-- 
2.49.0

[PATCH v1 bpf-next 1/5] af_unix: Call security_unix_may_send() in sendmsg() for all socket types

[Kuniyuki Iwashima]

Currently, security_unix_may_send() is invoked only for SOCK_DGRAM
sockets during connect() and sendmsg().

For SOCK_STREAM and SOCK_SEQPACKET sockets, an equivalent check
already occurs during connect(), making an additional hook in
sendmsg() unnecessary.

However, we want to leverage BPF LSM to inspect the skb during
sendmsg(), either to scrub file descriptors passed via SCM_RIGHTS
or to reject such an skb.

As a preparation, let's call security_unix_may_send() for SOCK_STREAM
and SOCK_SEQPACKET in sendmsg().

Note that SELinux, SMACK, and Landlock use security_unix_may_send().
To avoid unintentionally triggering the hook for SOCK_STREAM and
SOCK_SEQPACKET, an additional socket type check is added in each LSM.

Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 net/unix/af_unix.c         | 31 ++++++++++++++++++++++---------
 security/landlock/task.c   |  3 +++
 security/selinux/hooks.c   |  3 +++
 security/smack/smack_lsm.c |  3 +++
 4 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index f78a2492826f..769db3f8f41b 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2101,11 +2101,9 @@ static int unix_dgram_sendmsg(struct socket *sock, struct msghdr *msg,
 		goto out_unlock;
 	}
 
-	if (sk->sk_type != SOCK_SEQPACKET) {
-		err = security_unix_may_send(sk->sk_socket, other->sk_socket);
-		if (err)
-			goto out_unlock;
-	}
+	err = security_unix_may_send(sk->sk_socket, other->sk_socket);
+	if (err)
+		goto out_unlock;
 
 	/* other == sk && unix_peer(other) != sk if
 	 * - unix_peer(sk) == NULL, destination address bound to sk
@@ -2201,9 +2199,14 @@ static int queue_oob(struct socket *sock, struct msghdr *msg, struct sock *other
 
 	if (sock_flag(other, SOCK_DEAD) ||
 	    (other->sk_shutdown & RCV_SHUTDOWN)) {
-		unix_state_unlock(other);
 		err = -EPIPE;
-		goto out;
+		goto out_unlock;
+	}
+
+	if (!fds_sent) {
+		err = security_unix_may_send(sock, other->sk_socket);
+		if (err)
+			goto out_unlock;
 	}
 
 	maybe_add_creds(skb, sock, other);
@@ -2219,6 +2222,8 @@ static int queue_oob(struct socket *sock, struct msghdr *msg, struct sock *other
 	other->sk_data_ready(other);
 
 	return 0;
+out_unlock:
+	unix_state_unlock(other);
 out:
 	consume_skb(skb);
 	return err;
@@ -2296,8 +2301,6 @@ static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg,
 		if (err < 0)
 			goto out_free;
 
-		fds_sent = true;
-
 		if (unlikely(msg->msg_flags & MSG_SPLICE_PAGES)) {
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 			err = skb_splice_from_iter(skb, &msg->msg_iter, size,
@@ -2322,6 +2325,16 @@ static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg,
 		    (other->sk_shutdown & RCV_SHUTDOWN))
 			goto out_pipe_unlock;
 
+		if (!fds_sent) {
+			err = security_unix_may_send(sock, other->sk_socket);
+			if (err) {
+				unix_state_unlock(other);
+				goto out_free;
+			}
+		}
+
+		fds_sent = true;
+
 		maybe_add_creds(skb, sock, other);
 		scm_stat_add(other, skb);
 		skb_queue_tail(&other->sk_receive_queue, skb);
diff --git a/security/landlock/task.c b/security/landlock/task.c
index 2385017418ca..f15e6b0c56f8 100644
--- a/security/landlock/task.c
+++ b/security/landlock/task.c
@@ -305,6 +305,9 @@ static int hook_unix_may_send(struct socket *const sock,
 	if (!subject)
 		return 0;
 
+	if (sock->sk->sk_type != SOCK_DGRAM)
+		return 0;
+
 	/*
 	 * Checks if this datagram socket was already allowed to be connected
 	 * to other.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e7a7dcab81db..9fb4cd442ffd 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5106,6 +5106,9 @@ static int selinux_socket_unix_may_send(struct socket *sock,
 	struct common_audit_data ad;
 	struct lsm_network_audit net;
 
+	if (sock->sk->sk_type != SOCK_DGRAM)
+		return 0;
+
 	ad_net_init_from_sk(&ad, &net, other->sk);
 
 	return avc_has_perm(ssec->sid, osec->sid, osec->sclass, SOCKET__SENDTO,
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 99833168604e..00aa1e7513c1 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -3904,6 +3904,9 @@ static int smack_unix_may_send(struct socket *sock, struct socket *other)
 	smk_ad_setfield_u_net_sk(&ad, other->sk);
 #endif
 
+	if (sock->sk->sk_type != SOCK_DGRAM)
+		return 0;
+
 	if (smack_privileged(CAP_MAC_OVERRIDE))
 		return 0;
 
-- 
2.49.0

[PATCH v1 bpf-next 2/5] af_unix: Pass skb to security_unix_may_send().

[Kuniyuki Iwashima]

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.

Let's pass the skb to security_unix_may_send() so that BPF LSM can
inspect it and selectively prevent such a sendmsg().

Note that only the LSM_HOOK() macro uses the __nullable suffix for
skb to inform the verifier that the skb could be NULL at connect().
Without it, I was able to load a bpf prog without NULL check
against skb.

Sample:

SEC("lsm/unix_may_send")
int BPF_PROG(unix_refuse_scm_rights,
	     struct socket *sock, struct socket *other, struct sk_buff *skb)
{
	struct unix_skb_parms *cb;

	if (!skb)
		return 0;

	cb = (struct unix_skb_parms *)skb->cb;
	if (!cb->fp)
		return 0;

	return -EPERM;
}

Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
I guess there is no generic version of raw_tp_null_args[] ?
---
 include/linux/lsm_hook_defs.h | 3 ++-
 include/linux/security.h      | 5 +++--
 net/unix/af_unix.c            | 8 ++++----
 security/landlock/task.c      | 3 ++-
 security/security.c           | 5 +++--
 security/selinux/hooks.c      | 3 ++-
 security/smack/smack_lsm.c    | 3 ++-
 7 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index bf3bbac4e02a..762c7f2f7dee 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -318,7 +318,8 @@ LSM_HOOK(int, 0, watch_key, struct key *key)
 #ifdef CONFIG_SECURITY_NETWORK
 LSM_HOOK(int, 0, unix_stream_connect, struct sock *sock, struct sock *other,
 	 struct sock *newsk)
-LSM_HOOK(int, 0, unix_may_send, struct socket *sock, struct socket *other)
+LSM_HOOK(int, 0, unix_may_send, struct socket *sock, struct socket *other,
+	 struct sk_buff *skb__nullable)
 LSM_HOOK(int, 0, socket_create, int family, int type, int protocol, int kern)
 LSM_HOOK(int, 0, socket_post_create, struct socket *sock, int family, int type,
 	 int protocol, int kern)
diff --git a/include/linux/security.h b/include/linux/security.h
index cc9b54d95d22..5de77accee80 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1630,7 +1630,7 @@ static inline int security_watch_key(struct key *key)
 #ifdef CONFIG_SECURITY_NETWORK
 
 int security_unix_stream_connect(struct sock *sock, struct sock *other, struct sock *newsk);
-int security_unix_may_send(struct socket *sock,  struct socket *other);
+int security_unix_may_send(struct socket *sock,  struct socket *other, struct sk_buff *skb);
 int security_socket_create(int family, int type, int protocol, int kern);
 int security_socket_post_create(struct socket *sock, int family,
 				int type, int protocol, int kern);
@@ -1692,7 +1692,8 @@ static inline int security_unix_stream_connect(struct sock *sock,
 }
 
 static inline int security_unix_may_send(struct socket *sock,
-					 struct socket *other)
+					 struct socket *other,
+					 struct sk_buff *skb)
 {
 	return 0;
 }
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 769db3f8f41b..692cce579c89 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1447,7 +1447,7 @@ static int unix_dgram_connect(struct socket *sock, struct sockaddr *addr,
 		if (!unix_may_send(sk, other))
 			goto out_unlock;
 
-		err = security_unix_may_send(sk->sk_socket, other->sk_socket);
+		err = security_unix_may_send(sk->sk_socket, other->sk_socket, NULL);
 		if (err)
 			goto out_unlock;
 
@@ -2101,7 +2101,7 @@ static int unix_dgram_sendmsg(struct socket *sock, struct msghdr *msg,
 		goto out_unlock;
 	}
 
-	err = security_unix_may_send(sk->sk_socket, other->sk_socket);
+	err = security_unix_may_send(sk->sk_socket, other->sk_socket, skb);
 	if (err)
 		goto out_unlock;
 
@@ -2204,7 +2204,7 @@ static int queue_oob(struct socket *sock, struct msghdr *msg, struct sock *other
 	}
 
 	if (!fds_sent) {
-		err = security_unix_may_send(sock, other->sk_socket);
+		err = security_unix_may_send(sock, other->sk_socket, skb);
 		if (err)
 			goto out_unlock;
 	}
@@ -2326,7 +2326,7 @@ static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg,
 			goto out_pipe_unlock;
 
 		if (!fds_sent) {
-			err = security_unix_may_send(sock, other->sk_socket);
+			err = security_unix_may_send(sock, other->sk_socket, skb);
 			if (err) {
 				unix_state_unlock(other);
 				goto out_free;
diff --git a/security/landlock/task.c b/security/landlock/task.c
index f15e6b0c56f8..aeb712d3fa8f 100644
--- a/security/landlock/task.c
+++ b/security/landlock/task.c
@@ -295,7 +295,8 @@ static int hook_unix_stream_connect(struct sock *const sock,
 }
 
 static int hook_unix_may_send(struct socket *const sock,
-			      struct socket *const other)
+			      struct socket *const other,
+			      struct sk_buff *skb)
 {
 	size_t handle_layer;
 	const struct landlock_cred_security *const subject =
diff --git a/security/security.c b/security/security.c
index fb57e8fddd91..875dbc7ba34f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -4531,9 +4531,10 @@ EXPORT_SYMBOL(security_unix_stream_connect);
  *
  * Return: Returns 0 if permission is granted.
  */
-int security_unix_may_send(struct socket *sock,  struct socket *other)
+int security_unix_may_send(struct socket *sock,  struct socket *other,
+			   struct sk_buff *skb)
 {
-	return call_int_hook(unix_may_send, sock, other);
+	return call_int_hook(unix_may_send, sock, other, skb);
 }
 EXPORT_SYMBOL(security_unix_may_send);
 
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9fb4cd442ffd..fcf14fb76e7f 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5099,7 +5099,8 @@ static int selinux_socket_unix_stream_connect(struct sock *sock,
 }
 
 static int selinux_socket_unix_may_send(struct socket *sock,
-					struct socket *other)
+					struct socket *other,
+					struct sk_buff *skb)
 {
 	struct sk_security_struct *ssec = selinux_sock(sock->sk);
 	struct sk_security_struct *osec = selinux_sock(other->sk);
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 00aa1e7513c1..33827f4c5c76 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -3890,7 +3890,8 @@ static int smack_unix_stream_connect(struct sock *sock,
  * Return 0 if a subject with the smack of sock could access
  * an object with the smack of other, otherwise an error code
  */
-static int smack_unix_may_send(struct socket *sock, struct socket *other)
+static int smack_unix_may_send(struct socket *sock, struct socket *other,
+			       struct sk_buff *skb)
 {
 	struct socket_smack *ssp = smack_sock(sock->sk);
 	struct socket_smack *osp = smack_sock(other->sk);
-- 
2.49.0

[PATCH v1 bpf-next 3/5] af_unix: Remove redundant scm->fp check in __scm_destroy().

[Kuniyuki Iwashima]

__scm_destroy() is called from __scm_recv_common() or
scm_destroy(), and both of which check if scm->fp is NULL.

Let's remove the redundant scm->fp check in __scm_destroy().

While at it, we remove EXPORT_SYMBOL() for it and rename it
to scm_fp_destroy() to make the following patch clearer.

Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 include/net/scm.h |  5 +++--
 net/compat.c      |  2 +-
 net/core/scm.c    | 19 +++++++++----------
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/net/scm.h b/include/net/scm.h
index 22bb49589fde..058688a16a63 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -53,7 +53,7 @@ struct scm_cookie {
 void scm_detach_fds(struct msghdr *msg, struct scm_cookie *scm);
 void scm_detach_fds_compat(struct msghdr *msg, struct scm_cookie *scm);
 int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *scm);
-void __scm_destroy(struct scm_cookie *scm);
+void scm_fp_destroy(struct scm_cookie *scm);
 struct scm_fp_list *scm_fp_dup(struct scm_fp_list *fpl);
 
 #ifdef CONFIG_SECURITY_NETWORK
@@ -84,8 +84,9 @@ static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
 static __inline__ void scm_destroy(struct scm_cookie *scm)
 {
 	scm_destroy_cred(scm);
+
 	if (scm->fp)
-		__scm_destroy(scm);
+		scm_fp_destroy(scm);
 }
 
 static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
diff --git a/net/compat.c b/net/compat.c
index 485db8ee9b28..6689a4f37bcf 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -326,7 +326,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct scm_cookie *scm)
 	 * All of the files that fit in the message have had their usage counts
 	 * incremented, so we just free the list.
 	 */
-	__scm_destroy(scm);
+	scm_fp_destroy(scm);
 }
 
 /* Argument list sizes for compat_sys_socketcall */
diff --git a/net/core/scm.c b/net/core/scm.c
index 733c0cbd393d..bef8d008f910 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -130,20 +130,19 @@ static int scm_fp_copy(struct cmsghdr *cmsg, struct scm_fp_list **fplp)
 	return num;
 }
 
-void __scm_destroy(struct scm_cookie *scm)
+void scm_fp_destroy(struct scm_cookie *scm)
 {
 	struct scm_fp_list *fpl = scm->fp;
 	int i;
 
-	if (fpl) {
-		scm->fp = NULL;
-		for (i=fpl->count-1; i>=0; i--)
-			fput(fpl->fp[i]);
-		free_uid(fpl->user);
-		kfree(fpl);
-	}
+	scm->fp = NULL;
+
+	for (i = fpl->count - 1; i >= 0; i--)
+		fput(fpl->fp[i]);
+
+	free_uid(fpl->user);
+	kfree(fpl);
 }
-EXPORT_SYMBOL(__scm_destroy);
 
 int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
 {
@@ -375,7 +374,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie *scm)
 	 * All of the files that fit in the message have had their usage counts
 	 * incremented, so we just free the list.
 	 */
-	__scm_destroy(scm);
+	scm_fp_destroy(scm);
 }
 EXPORT_SYMBOL(scm_detach_fds);
 
-- 
2.49.0

Re: [PATCH v1 bpf-next 3/5] af_unix: Remove redundant scm->fp check in __scm_destroy().

[kernel test robot]

Hi Kuniyuki,

kernel test robot noticed the following build errors:

[auto build test ERROR on bpf-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Kuniyuki-Iwashima/af_unix-Call-security_unix_may_send-in-sendmsg-for-all-socket-types/20250506-060219
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link:    https://lore.kernel.org/r/20250505215802.48449-4-kuniyu%40amazon.com
patch subject: [PATCH v1 bpf-next 3/5] af_unix: Remove redundant scm->fp check in __scm_destroy().
config: i386-randconfig-054-20250509 (https://download.01.org/0day-ci/archive/20250509/202505092103.UWs7ZtbF-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250509/202505092103.UWs7ZtbF-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505092103.UWs7ZtbF-lkp@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "scm_fp_destroy" [net/bluetooth/bluetooth.ko] undefined!

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().

[Kuniyuki Iwashima]

As Christian Brauner said [0], 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 that close() for unwanted file
descriptors could block longer 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.

Let's add a new kfunc to scrub all file descriptors from skb in
sendmsg().

This allows the receiver to keep recv()ing the bare data and disallows
the sender to impose the potential slowness of the last fput().

If necessary, we can add more granular filtering per file descriptor
after refactoring GC code and adding some fd-to-file helpers for BPF.

Sample:

SEC("lsm/unix_may_send")
int BPF_PROG(unix_scrub_scm_rights,
             struct socket *sock, struct socket *other, struct sk_buff *skb)
{
        struct unix_skb_parms *cb;

        if (skb && bpf_unix_scrub_fds(skb))
                return -EPERM;

        return 0;
}

Link: https://lore.kernel.org/netdev/20250502-fanden-unbeschadet-89973225255f@brauner/ #[0]
Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 include/net/af_unix.h |  1 +
 net/core/filter.c     | 19 +++++++++++++++++--
 net/unix/af_unix.c    | 15 +++++++++++++++
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 1af1841b7601..109f92df2de2 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -58,4 +58,5 @@ struct unix_sock {
 #define unix_state_lock(s)	spin_lock(&unix_sk(s)->lock)
 #define unix_state_unlock(s)	spin_unlock(&unix_sk(s)->lock)
 
+int unix_scrub_fds(struct sk_buff *skb);
 #endif
diff --git a/net/core/filter.c b/net/core/filter.c
index 79cab4d78dc3..a9c46584da10 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -82,7 +82,7 @@
 #include <net/mptcp.h>
 #include <net/netfilter/nf_conntrack_bpf.h>
 #include <net/netkit.h>
-#include <linux/un.h>
+#include <net/af_unix.h>
 #include <net/xdp_sock_drv.h>
 #include <net/inet_dscp.h>
 
@@ -12153,6 +12153,11 @@ __bpf_kfunc int bpf_sock_ops_enable_tx_tstamp(struct bpf_sock_ops_kern *skops,
 	return 0;
 }
 
+__bpf_kfunc int bpf_unix_scrub_fds(struct sk_buff *skb)
+{
+	return unix_scrub_fds(skb);
+}
+
 __bpf_kfunc_end_defs();
 
 int bpf_dynptr_from_skb_rdonly(struct __sk_buff *skb, u64 flags,
@@ -12190,6 +12195,10 @@ BTF_KFUNCS_START(bpf_kfunc_check_set_sock_ops)
 BTF_ID_FLAGS(func, bpf_sock_ops_enable_tx_tstamp, KF_TRUSTED_ARGS)
 BTF_KFUNCS_END(bpf_kfunc_check_set_sock_ops)
 
+BTF_KFUNCS_START(bpf_kfunc_check_set_scm_rights)
+BTF_ID_FLAGS(func, bpf_unix_scrub_fds, KF_TRUSTED_ARGS)
+BTF_KFUNCS_END(bpf_kfunc_check_set_scm_rights)
+
 static const struct btf_kfunc_id_set bpf_kfunc_set_skb = {
 	.owner = THIS_MODULE,
 	.set = &bpf_kfunc_check_set_skb,
@@ -12215,6 +12224,11 @@ static const struct btf_kfunc_id_set bpf_kfunc_set_sock_ops = {
 	.set = &bpf_kfunc_check_set_sock_ops,
 };
 
+static const struct btf_kfunc_id_set bpf_kfunc_set_scm_rights = {
+	.owner = THIS_MODULE,
+	.set = &bpf_kfunc_check_set_scm_rights,
+};
+
 static int __init bpf_kfunc_init(void)
 {
 	int ret;
@@ -12234,7 +12248,8 @@ static int __init bpf_kfunc_init(void)
 	ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
 					       &bpf_kfunc_set_sock_addr);
 	ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS, &bpf_kfunc_set_tcp_reqsk);
-	return ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SOCK_OPS, &bpf_kfunc_set_sock_ops);
+	ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SOCK_OPS, &bpf_kfunc_set_sock_ops);
+	return ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_LSM, &bpf_kfunc_set_scm_rights);
 }
 late_initcall(bpf_kfunc_init);
 
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 692cce579c89..4c088316dfb7 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1885,6 +1885,21 @@ static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool sen
 	return err;
 }
 
+int unix_scrub_fds(struct sk_buff *skb)
+{
+	struct scm_cookie scm = {};
+
+	if (skb->destructor != unix_destruct_scm)
+		return -EINVAL;
+
+	if (UNIXCB(skb).fp) {
+		unix_detach_fds(&scm, skb);
+		scm_fp_destroy(&scm);
+	}
+
+	return 0;
+}
+
 static bool unix_passcred_enabled(const struct socket *sock,
 				  const struct sock *other)
 {
-- 
2.49.0

Re: [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().

[Alexei Starovoitov]

On Mon, May 5, 2025 at 3:00 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> As Christian Brauner said [0], 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 that close() for unwanted file
> descriptors could block longer 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.
>
> Let's add a new kfunc to scrub all file descriptors from skb in
> sendmsg().
>
> This allows the receiver to keep recv()ing the bare data and disallows
> the sender to impose the potential slowness of the last fput().
>
> If necessary, we can add more granular filtering per file descriptor
> after refactoring GC code and adding some fd-to-file helpers for BPF.
>
> Sample:
>
> SEC("lsm/unix_may_send")
> int BPF_PROG(unix_scrub_scm_rights,
>              struct socket *sock, struct socket *other, struct sk_buff *skb)
> {
>         struct unix_skb_parms *cb;
>
>         if (skb && bpf_unix_scrub_fds(skb))
>                 return -EPERM;
>
>         return 0;
> }

Any other programmability do you need there?

If not and above is all that is needed then what Jann proposed
sounds like better path to me:
"
I think the thorough fix would probably be to introduce a socket
option (controlled via setsockopt()) that already blocks the peer's
sendmsg().
"

Easier to operate and upriv process can use such setsockopt() too.

Re: [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().

[Mickaël Salaün]

On Mon, May 05, 2025 at 05:13:32PM -0700, Alexei Starovoitov wrote:
> On Mon, May 5, 2025 at 3:00 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >
> > As Christian Brauner said [0], 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 that close() for unwanted file
> > descriptors could block longer 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.
> >
> > Let's add a new kfunc to scrub all file descriptors from skb in
> > sendmsg().
> >
> > This allows the receiver to keep recv()ing the bare data and disallows
> > the sender to impose the potential slowness of the last fput().
> >
> > If necessary, we can add more granular filtering per file descriptor
> > after refactoring GC code and adding some fd-to-file helpers for BPF.
> >
> > Sample:
> >
> > SEC("lsm/unix_may_send")
> > int BPF_PROG(unix_scrub_scm_rights,
> >              struct socket *sock, struct socket *other, struct sk_buff *skb)
> > {
> >         struct unix_skb_parms *cb;
> >
> >         if (skb && bpf_unix_scrub_fds(skb))
> >                 return -EPERM;
> >
> >         return 0;
> > }
> 
> Any other programmability do you need there?
> 
> If not and above is all that is needed then what Jann proposed
> sounds like better path to me:
> "
> I think the thorough fix would probably be to introduce a socket
> option (controlled via setsockopt()) that already blocks the peer's
> sendmsg().
> "
> 
> Easier to operate and upriv process can use such setsockopt() too.

Adding a flag with setsockopt() will enable any program to protect
themselves instead of requiring the capability to load an eBPF program.
For the systemd use case, I think a flag would be enough, and it would
benefit more than only/mainly systemd.

Another thing is that we should have a consistent user space error code
if passing file descriptors is denied, to avoid confusing senders, to
not silently ignore dropped file descriptors, and to let the sender know
that it can send again but without passed file descriptors or maybe with
a maximum number of file descriptors.  The ENFILE errno (file table
overflow) looks like a good candidate.

I guess both approaches are valuable, but this series should add this
new flag as well, and specify the expected error handling.

If we want to be able to handle legacy software not using this new flag,
we can leverage seccomp unotify.

Re: [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().

[kernel test robot]

Hi Kuniyuki,

kernel test robot noticed the following build errors:

[auto build test ERROR on bpf-next/master]

url:    https://github.com/intel-lab-lkp/linux/commits/Kuniyuki-Iwashima/af_unix-Call-security_unix_may_send-in-sendmsg-for-all-socket-types/20250506-060219
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link:    https://lore.kernel.org/r/20250505215802.48449-5-kuniyu%40amazon.com
patch subject: [PATCH v1 bpf-next 4/5] bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().
config: csky-randconfig-001-20250509 (https://download.01.org/0day-ci/archive/20250509/202505092221.8wrWSFI7-lkp@intel.com/config)
compiler: csky-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250509/202505092221.8wrWSFI7-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505092221.8wrWSFI7-lkp@intel.com/

All errors (new ones prefixed by >>):

   csky-linux-ld: net/core/filter.o: in function `bpf_unix_scrub_fds':
>> filter.c:(.text+0xc796): undefined reference to `unix_scrub_fds'
   csky-linux-ld: net/core/filter.o: in function `bpf_sock_destroy':
   filter.c:(.text+0xc7dc): undefined reference to `unix_scrub_fds'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v1 bpf-next 5/5] selftest: bpf: Add test for bpf_unix_scrub_fds().

[Kuniyuki Iwashima]

This test performs the following for all AF_UNIX socket types

  1. Create a socket pair (sender and receiver)
  2. Send the receiver's fd from the sender to the receiver
  3. Receive the fd
  4. Attach a BPF LSM prog that scrubs SCM_RIGHTS fds
  5. Send the receiver's fd from the sender to the receiver
  6. Check if the fd was scrubbed
  7. Detach the LSM prog

How to run:

  # make -C tools/testing/selftests/bpf/
  # ./tools/testing/selftests/bpf/test_progs -t lsm_unix_may_send
  ...
  #175/1   lsm_unix_may_send/SOCK_STREAM:OK
  #175/2   lsm_unix_may_send/SOCK_DGRAM:OK
  #175/3   lsm_unix_may_send/SOCK_SEQPACKET:OK
  #175     lsm_unix_may_send:OK
  Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 .../bpf/prog_tests/lsm_unix_may_send.c        | 160 ++++++++++++++++++
 .../selftests/bpf/progs/lsm_unix_may_send.c   |  30 ++++
 2 files changed, 190 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_unix_may_send.c
 create mode 100644 tools/testing/selftests/bpf/progs/lsm_unix_may_send.c

diff --git a/tools/testing/selftests/bpf/prog_tests/lsm_unix_may_send.c b/tools/testing/selftests/bpf/prog_tests/lsm_unix_may_send.c
new file mode 100644
index 000000000000..50b2547e63cf
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/lsm_unix_may_send.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright Amazon.com Inc. or its affiliates. */
+
+#include "test_progs.h"
+#include "lsm_unix_may_send.skel.h"
+
+#define MSG_HELLO "Hello"
+#define MSG_WORLD "World"
+#define MSG_LEN 5
+
+struct scm_rights {
+	struct cmsghdr cmsghdr;
+	int fd;
+};
+
+static int send_fd(int sender_fd, int receiver_fd)
+{
+	struct scm_rights cmsg = {};
+	struct msghdr msg = {};
+	struct iovec iov = {};
+	int ret;
+
+	msg.msg_iov = &iov;
+	msg.msg_iovlen = 1;
+	msg.msg_control = &cmsg;
+	msg.msg_controllen = CMSG_SPACE(sizeof(cmsg.fd));
+
+	iov.iov_base = MSG_HELLO;
+	iov.iov_len = MSG_LEN;
+
+	cmsg.cmsghdr.cmsg_len = CMSG_LEN(sizeof(cmsg.fd));
+	cmsg.cmsghdr.cmsg_level = SOL_SOCKET;
+	cmsg.cmsghdr.cmsg_type = SCM_RIGHTS;
+	cmsg.fd = receiver_fd;
+
+	ret = sendmsg(sender_fd, &msg, 0);
+	if (!ASSERT_EQ(ret, MSG_LEN, "sendmsg(Hello)"))
+		return -EINVAL;
+
+	ret = send(sender_fd, MSG_WORLD, MSG_LEN, 0);
+	if (!ASSERT_EQ(ret, MSG_LEN, "sendmsg(World)"))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int recv_fd(int receiver_fd, bool lsm_attached)
+{
+	struct scm_rights cmsg = {};
+	struct msghdr msg = {};
+	char buf[MSG_LEN] = {};
+	struct iovec iov = {};
+	int ret;
+
+	msg.msg_iov = &iov;
+	msg.msg_iovlen = 1;
+	msg.msg_control = &cmsg;
+	msg.msg_controllen = CMSG_SPACE(sizeof(cmsg.fd));
+
+	iov.iov_base = buf;
+	iov.iov_len = sizeof(buf);
+
+	ret = recvmsg(receiver_fd, &msg, 0);
+	if (!ASSERT_EQ(ret, MSG_LEN, "recvmsg(Hello) length") ||
+	    !ASSERT_STRNEQ(buf, MSG_HELLO, MSG_LEN, "recvmsg(Hello) data"))
+		return -EINVAL;
+
+	if (lsm_attached) {
+		if (!ASSERT_ERR_PTR(CMSG_FIRSTHDR(&msg), "cmsg filtered"))
+			return -EINVAL;
+	} else {
+		if (!ASSERT_OK_PTR(CMSG_FIRSTHDR(&msg), "cmsg sent") ||
+		    !ASSERT_EQ(cmsg.cmsghdr.cmsg_len, CMSG_LEN(sizeof(cmsg.fd)), "cmsg_len") ||
+		    !ASSERT_EQ(cmsg.cmsghdr.cmsg_level, SOL_SOCKET, "cmsg_level") ||
+		    !ASSERT_EQ(cmsg.cmsghdr.cmsg_type, SCM_RIGHTS, "cmsg_type"))
+			return -EINVAL;
+
+		receiver_fd = cmsg.fd;
+	}
+
+	memset(buf, 0, sizeof(buf));
+
+	ret = recv(receiver_fd, buf, sizeof(buf), 0);
+	if (!ASSERT_EQ(ret, MSG_LEN, "recvmsg(World) length") ||
+	    !ASSERT_STRNEQ(buf, MSG_WORLD, MSG_LEN, "recvmsg(World) data"))
+		return -EINVAL;
+
+	return 0;
+}
+
+static void test_scm_rights(struct lsm_unix_may_send *skel, int type)
+{
+	struct bpf_link *link;
+	int socket_fds[2];
+	int err;
+
+	err = socketpair(AF_UNIX, type, 0, socket_fds);
+	if (!ASSERT_EQ(err, 0, "socketpair"))
+		return;
+
+	err = send_fd(socket_fds[0], socket_fds[1]);
+	if (err)
+		goto close;
+
+	err = recv_fd(socket_fds[1], false);
+	if (err)
+		goto close;
+
+	link = bpf_program__attach_lsm(skel->progs.unix_scrub_scm_rights);
+	if (!ASSERT_OK_PTR(link, "attach lsm"))
+		goto close;
+
+	err = send_fd(socket_fds[0], socket_fds[1]);
+	if (err)
+		goto close;
+
+	err = recv_fd(socket_fds[1], true);
+	if (err)
+		goto close;
+
+	err = bpf_link__destroy(link);
+	ASSERT_EQ(err, 0, "destroy lsm");
+close:
+	close(socket_fds[0]);
+	close(socket_fds[1]);
+}
+
+struct sk_type {
+	char name[16];
+	int type;
+} sk_types[] = {
+	{
+		.name = "SOCK_STREAM",
+		.type = SOCK_STREAM,
+	},
+	{
+		.name = "SOCK_DGRAM",
+		.type = SOCK_DGRAM,
+	},
+	{
+		.name = "SOCK_SEQPACKET",
+		.type = SOCK_SEQPACKET,
+	},
+};
+
+void test_lsm_unix_may_send(void)
+{
+	struct lsm_unix_may_send *skel;
+	int i;
+
+	skel = lsm_unix_may_send__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "load skel"))
+		return;
+
+	for (i = 0; i < ARRAY_SIZE(sk_types); i++)
+		if (test__start_subtest(sk_types[i].name))
+			test_scm_rights(skel, sk_types[i].type);
+
+	lsm_unix_may_send__destroy(skel);
+}
diff --git a/tools/testing/selftests/bpf/progs/lsm_unix_may_send.c b/tools/testing/selftests/bpf/progs/lsm_unix_may_send.c
new file mode 100644
index 000000000000..c2459ba2c33d
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/lsm_unix_may_send.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright Amazon.com Inc. or its affiliates. */
+
+#include "vmlinux.h"
+#include <bpf/bpf_tracing.h>
+
+#ifndef EPERM
+#define EPERM 1
+#endif
+
+SEC("lsm/unix_may_send")
+int BPF_PROG(unix_scrub_scm_rights,
+	     struct socket *sock, struct socket *other, struct sk_buff *skb)
+{
+	struct unix_skb_parms *cb;
+
+	if (!skb)
+		return 0;
+
+	cb = (struct unix_skb_parms *)skb->cb;
+	if (!cb->fp)
+		return 0;
+
+	if (bpf_unix_scrub_fds(skb))
+		return -EPERM;
+
+	return 0;
+}
+
+char _license[] SEC("license") = "GPL";
-- 
2.49.0

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

[Kumar Kartikeya Dwivedi]

On Mon, 5 May 2025 at 23:58, 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.
>
> Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
> Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
>

This sounds pretty useful!

I think you should mention the cases of possible DoS on close() or
flooding, e.g. with FUSE controlled fd/NFS hangs in the commit log
itself.
I think it's been an open problem for a while now with no good solution.
Currently systemd's FDSTORE=1 for PID 1 is susceptible to the same
problem, even if the underlying service isn't root.

I think it is also useful for restricting what individual file
descriptors can be passed around by a process.
Say restricting usage of an fd to a process and its children, but not
allowing it to be shared with others.
Send side hook is the right point to enforce it.

Therefore exercising scm_fp_list would be a good idea.
We should provide some more examples of the filtering policy in the selftests.
Maybe a simple example, e.g. only memfd or a pipe fd can be passed,
and nothing else.
It would require checking file->f_ops.
I don't think "scrub all file descriptors" is the only possible usage scenario.
In the case of FDSTORE=1, it might be "everything except fuse or NFS fds" etc.

Eventually if file local storage happens, more interesting policies
may be possible.

> [...]

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

[Kuniyuki Iwashima]

From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date: Tue, 6 May 2025 00:49:11 +0200
> On Mon, 5 May 2025 at 23:58, 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.
> >
> > Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
> > Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
> >
> 
> This sounds pretty useful!
> 
> I think you should mention the cases of possible DoS on close() or
> flooding, e.g. with FUSE controlled fd/NFS hangs in the commit log
> itself.
> I think it's been an open problem for a while now with no good solution.
> Currently systemd's FDSTORE=1 for PID 1 is susceptible to the same
> problem, even if the underlying service isn't root.

Good point, will add the description in v2.


> 
> I think it is also useful for restricting what individual file
> descriptors can be passed around by a process.
> Say restricting usage of an fd to a process and its children, but not
> allowing it to be shared with others.
> Send side hook is the right point to enforce it.

Agreed.

Actually, I tried per-fd filtering first and failed somehow so
wanted some advice from BPF folks :)

For example, I implemented kfunc like:

__bpf_kfunc int bpf_unix_scrub_file(struct sk_buff *skb, struct file *filp)
{
	/* scrub fd matching file if exists */
}

and tried filp == NULL -> scrub all so that I can gradually extend
the functionality, but verifier didn't allow passing NULL.

Also, once a fd is scrubbed, I do not want to leave the array entry
empty to avoid adding unnecessary "if (fpl->fp[i] == -1)" test in
other places.

       struct scm_fp_list *fpl = UNIXCB(skb).fp;

       /* scrubbed fpl->fp[i] here. */

       fpl->fp[i] = fpl->fp[fpl->count - 1];
       fpl->count--;

But this could confuse BPF prog if it was iterating fpl->fp[] in for
loop and I was wondering how the interface should be like.

  * Keep the empty index and ignore at core code ?
  * Provide a fd iterator ?
  * Scrub based on index ? matching fd ? or struct file ?
    * -1 works as ALL_INDEX or ALL_FDS but NULL doesn't
  * Invoke BPF LSM per-fd ?
    * Maybe no as sender/receiver pair is always same for the same skb

I guess keeping the empty index as is and index based scrubbing
would be simpler and cleaner ?


> 
> Therefore exercising scm_fp_list would be a good idea.
> We should provide some more examples of the filtering policy in the selftests.
> Maybe a simple example, e.g. only memfd or a pipe fd can be passed,
> and nothing else.
> It would require checking file->f_ops.

Yes, and I thought we need fd-to-file kfunc or BPF helper, but I was
not sure which would be better as both functionality should be stable.
But given the user needs to inspect the raw scm_fp_list, kfunc is better ?

* bpf_fd_to_file()
or
* bpf_unix_get_scm_rights() -> return struct file ?

plus

* bpf_unix_scrub_scm_rights() -> scrub based on fd or file ?


> 
> I don't think "scrub all file descriptors" is the only possible usage scenario.
> In the case of FDSTORE=1, it might be "everything except fuse or NFS fds" etc.
> 
> Eventually if file local storage happens, more interesting policies
> may be possible.
> 

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

[Kumar Kartikeya Dwivedi]

On Tue, 6 May 2025 at 02:28, Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Date: Tue, 6 May 2025 00:49:11 +0200
> > On Mon, 5 May 2025 at 23:58, 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.
> > >
> > > Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
> > > Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
> > >
> >
> > This sounds pretty useful!
> >
> > I think you should mention the cases of possible DoS on close() or
> > flooding, e.g. with FUSE controlled fd/NFS hangs in the commit log
> > itself.
> > I think it's been an open problem for a while now with no good solution.
> > Currently systemd's FDSTORE=1 for PID 1 is susceptible to the same
> > problem, even if the underlying service isn't root.
>
> Good point, will add the description in v2.
>
>
> >
> > I think it is also useful for restricting what individual file
> > descriptors can be passed around by a process.
> > Say restricting usage of an fd to a process and its children, but not
> > allowing it to be shared with others.
> > Send side hook is the right point to enforce it.
>
> Agreed.
>
> Actually, I tried per-fd filtering first and failed somehow so
> wanted some advice from BPF folks :)
>
> For example, I implemented kfunc like:
>
> __bpf_kfunc int bpf_unix_scrub_file(struct sk_buff *skb, struct file *filp)
> {
>         /* scrub fd matching file if exists */
> }
>
> and tried filp == NULL -> scrub all so that I can gradually extend
> the functionality, but verifier didn't allow passing NULL.
>
> Also, once a fd is scrubbed, I do not want to leave the array entry
> empty to avoid adding unnecessary "if (fpl->fp[i] == -1)" test in
> other places.
>
>        struct scm_fp_list *fpl = UNIXCB(skb).fp;
>
>        /* scrubbed fpl->fp[i] here. */
>
>        fpl->fp[i] = fpl->fp[fpl->count - 1];
>        fpl->count--;
>
> But this could confuse BPF prog if it was iterating fpl->fp[] in for
> loop and I was wondering how the interface should be like.
>
>   * Keep the empty index and ignore at core code ?
>   * Provide a fd iterator ?
>   * Scrub based on index ? matching fd ? or struct file ?
>     * -1 works as ALL_INDEX or ALL_FDS but NULL doesn't
>   * Invoke BPF LSM per-fd ?
>     * Maybe no as sender/receiver pair is always same for the same skb
>
> I guess keeping the empty index as is and index based scrubbing
> would be simpler and cleaner ?
>
>
> >
> > Therefore exercising scm_fp_list would be a good idea.
> > We should provide some more examples of the filtering policy in the selftests.
> > Maybe a simple example, e.g. only memfd or a pipe fd can be passed,
> > and nothing else.
> > It would require checking file->f_ops.
>
> Yes, and I thought we need fd-to-file kfunc or BPF helper, but I was
> not sure which would be better as both functionality should be stable.
> But given the user needs to inspect the raw scm_fp_list, kfunc is better ?
>
> * bpf_fd_to_file()
> or
> * bpf_unix_get_scm_rights() -> return struct file ?
>
> plus
>
> * bpf_unix_scrub_scm_rights() -> scrub based on fd or file ?
>
>

Given you're probably going to drop scrubbing, all you'd need is to
pass the pointer to file to inspect is f = bpf_core_cast(&fpl->fp[i],
struct file).
Then just find out the type of file using f->f_ops == something and if
a disallowed file type is seen, return the verdict.

> [...]

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

[Kuniyuki Iwashima]

From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date: Tue, 6 May 2025 18:25:14 +0200
> Given you're probably going to drop scrubbing, all you'd need is to
> pass the pointer to file to inspect is f = bpf_core_cast(&fpl->fp[i],
> struct file).

Ah, I totally forgot bpf_core_cast().


> Then just find out the type of file using f->f_ops == something and if
> a disallowed file type is seen, return the verdict.

I'll change selftest as such.

Thanks!

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

[Christian Brauner]

On Tue, May 06, 2025 at 12:49:11AM +0200, Kumar Kartikeya Dwivedi wrote:
> On Mon, 5 May 2025 at 23:58, 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.
> >
> > Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
> > Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
> >
> 
> This sounds pretty useful!
> 
> I think you should mention the cases of possible DoS on close() or
> flooding, e.g. with FUSE controlled fd/NFS hangs in the commit log
> itself.
> I think it's been an open problem for a while now with no good solution.
> Currently systemd's FDSTORE=1 for PID 1 is susceptible to the same
> problem, even if the underlying service isn't root.
> 
> I think it is also useful for restricting what individual file
> descriptors can be passed around by a process.
> Say restricting usage of an fd to a process and its children, but not
> allowing it to be shared with others.
> Send side hook is the right point to enforce it.
> 
> Therefore exercising scm_fp_list would be a good idea.

No, that's a terrible idea. If the receiver expects 10 file descriptors
and suddenly some magically disappear or the order gets messed up that's
terrible for security. It's either close all or nothing.

> We should provide some more examples of the filtering policy in the selftests.
> Maybe a simple example, e.g. only memfd or a pipe fd can be passed,
> and nothing else.
> It would require checking file->f_ops.

There's not going to be poking around in file->f_ops for this.

Really, what I asked for was a simple way to set a socket option without
any bpf or lsm involvement so even really dumb userspace can simply
block receiving any file descriptors. How that spiraled into "let's
apply arbitrary filters on SCM_RIGHTS and make files disappear on the
way" is beyond me.

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

[Kumar Kartikeya Dwivedi]

On Tue, 6 May 2025 at 11:15, Christian Brauner <brauner@kernel.org> wrote:
>
> On Tue, May 06, 2025 at 12:49:11AM +0200, Kumar Kartikeya Dwivedi wrote:
> > On Mon, 5 May 2025 at 23:58, 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.
> > >
> > > Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
> > > Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
> > >
> >
> > This sounds pretty useful!
> >
> > I think you should mention the cases of possible DoS on close() or
> > flooding, e.g. with FUSE controlled fd/NFS hangs in the commit log
> > itself.
> > I think it's been an open problem for a while now with no good solution.
> > Currently systemd's FDSTORE=1 for PID 1 is susceptible to the same
> > problem, even if the underlying service isn't root.
> >
> > I think it is also useful for restricting what individual file
> > descriptors can be passed around by a process.
> > Say restricting usage of an fd to a process and its children, but not
> > allowing it to be shared with others.
> > Send side hook is the right point to enforce it.
> >
> > Therefore exercising scm_fp_list would be a good idea.
>
> No, that's a terrible idea. If the receiver expects 10 file descriptors
> and suddenly some magically disappear or the order gets messed up that's
> terrible for security. It's either close all or nothing.

I was talking about exercising/reading it in the selftest, not
exposing anything new.

Yes, the policy should be close all or nothing, but it can still be
used to deny sendmsg when one of the descriptors being passed isn't in
the allowed set.
You just return 0 or an error. No need to scrub, no need to disappear
some fds and let the message pass, which can be problematic.

>
> > We should provide some more examples of the filtering policy in the selftests.
> > Maybe a simple example, e.g. only memfd or a pipe fd can be passed,
> > and nothing else.
> > It would require checking file->f_ops.
>
> There's not going to be poking around in file->f_ops for this.

I don't think any poking is required. There's no need to expose anything extra.

Really, all that is needed is for an LSM hook to exist and the program
to say success or failure.
Even the scrub fds stuff can be dropped.

The program can simply inspect the scm_fp_list and if it doesn't look
ok, deny the sendmsg.
It's already there inside unix_skb_parms.

It just means the program can look at the file (there's no helper
needed to be exposed) and make a decision, just like in the rest of
the BPF LSM hooks.
I think a socket option makes sense too, but ideally we can have both
the hook and the socket option.

The socket option has the advantage that user space can set it itself
conveniently, without having to load a BPF program.
Meanwhile the hook can be more fine grained in decision making and be
imposed by some central entity.

Does this sound reasonable? I don't think it requires anything beyond
simply defining the hook and letting a program run there.
No poking into VFS internals etc. or silently dropping file
descriptors and letting it succeed.

So mostly patch 1-2 and then another to add a setsockopt flag.

>
> [...]

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

[Kuniyuki Iwashima]

From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date: Tue, 6 May 2025 18:08:23 +0200
> On Tue, 6 May 2025 at 11:15, Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Tue, May 06, 2025 at 12:49:11AM +0200, Kumar Kartikeya Dwivedi wrote:
> > > On Mon, 5 May 2025 at 23:58, 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.
> > > >
> > > > Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
> > > > Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
> > > >
> > >
> > > This sounds pretty useful!
> > >
> > > I think you should mention the cases of possible DoS on close() or
> > > flooding, e.g. with FUSE controlled fd/NFS hangs in the commit log
> > > itself.
> > > I think it's been an open problem for a while now with no good solution.
> > > Currently systemd's FDSTORE=1 for PID 1 is susceptible to the same
> > > problem, even if the underlying service isn't root.
> > >
> > > I think it is also useful for restricting what individual file
> > > descriptors can be passed around by a process.
> > > Say restricting usage of an fd to a process and its children, but not
> > > allowing it to be shared with others.
> > > Send side hook is the right point to enforce it.
> > >
> > > Therefore exercising scm_fp_list would be a good idea.
> >
> > No, that's a terrible idea. If the receiver expects 10 file descriptors
> > and suddenly some magically disappear or the order gets messed up that's
> > terrible for security. It's either close all or nothing.
> 
> I was talking about exercising/reading it in the selftest, not
> exposing anything new.
> 
> Yes, the policy should be close all or nothing, but it can still be
> used to deny sendmsg when one of the descriptors being passed isn't in
> the allowed set.
> You just return 0 or an error. No need to scrub, no need to disappear
> some fds and let the message pass, which can be problematic.
> 
> >
> > > We should provide some more examples of the filtering policy in the selftests.
> > > Maybe a simple example, e.g. only memfd or a pipe fd can be passed,
> > > and nothing else.
> > > It would require checking file->f_ops.
> >
> > There's not going to be poking around in file->f_ops for this.
> 
> I don't think any poking is required. There's no need to expose anything extra.
> 
> Really, all that is needed is for an LSM hook to exist and the program
> to say success or failure.
> Even the scrub fds stuff can be dropped.
> 
> The program can simply inspect the scm_fp_list and if it doesn't look
> ok, deny the sendmsg.
> It's already there inside unix_skb_parms.
> 
> It just means the program can look at the file (there's no helper
> needed to be exposed) and make a decision, just like in the rest of
> the BPF LSM hooks.
> I think a socket option makes sense too, but ideally we can have both
> the hook and the socket option.
> 
> The socket option has the advantage that user space can set it itself
> conveniently, without having to load a BPF program.
> Meanwhile the hook can be more fine grained in decision making and be
> imposed by some central entity.
> 
> Does this sound reasonable? I don't think it requires anything beyond
> simply defining the hook and letting a program run there.
> No poking into VFS internals etc. or silently dropping file
> descriptors and letting it succeed.
> 
> So mostly patch 1-2 and then another to add a setsockopt flag.

Right, patch 1-2 is enough to let BPF LSM to filter each skb.

I'll also add the socket option too.

Thanks!

Re: [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 5:58 PM 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.

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?

> Link: https://uapi-group.org/kernel-features/#disabling-reception-of-scm_rights-for-af_unix-sockets #[0]
> Link: https://github.com/systemd/systemd/blob/v257.5/src/basic/fd-util.c#L612-L628 #[1]
>
>
> Kuniyuki Iwashima (5):
>   af_unix: Call security_unix_may_send() in sendmsg() for all socket
>     types
>   af_unix: Pass skb to security_unix_may_send().
>   af_unix: Remove redundant scm->fp check in __scm_destroy().
>   bpf: Add kfunc to scrub SCM_RIGHTS at security_unix_may_send().
>   selftest: bpf: Add test for bpf_unix_scrub_fds().
>
>  include/linux/lsm_hook_defs.h                 |   3 +-
>  include/linux/security.h                      |   5 +-
>  include/net/af_unix.h                         |   1 +
>  include/net/scm.h                             |   5 +-
>  net/compat.c                                  |   2 +-
>  net/core/filter.c                             |  19 ++-
>  net/core/scm.c                                |  19 +--
>  net/unix/af_unix.c                            |  48 ++++--
>  security/landlock/task.c                      |   6 +-
>  security/security.c                           |   5 +-
>  security/selinux/hooks.c                      |   6 +-
>  security/smack/smack_lsm.c                    |   6 +-
>  .../bpf/prog_tests/lsm_unix_may_send.c        | 160 ++++++++++++++++++
>  .../selftests/bpf/progs/lsm_unix_may_send.c   |  30 ++++
>  14 files changed, 282 insertions(+), 33 deletions(-)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/lsm_unix_may_send.c
>  create mode 100644 tools/testing/selftests/bpf/progs/lsm_unix_may_send.c
>
> --
> 2.49.0

--
paul-moore.com

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

[Kuniyuki Iwashima]

From: Paul Moore <paul@paul-moore.com>
Date: Mon, 5 May 2025 19:21:25 -0400
> On Mon, May 5, 2025 at 5:58 PM 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.
> 
> 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.

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.

Re: [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@amazon.com> wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Mon, 5 May 2025 19:21:25 -0400
> > On Mon, May 5, 2025 at 5:58 PM 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.
> >
> > 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

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

[Lennart Poettering]

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

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

[Kuniyuki Iwashima]

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!