public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jori Koolstra <jkoolstra@xs4all.nl>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Eric Dumazet <edumazet@google.com>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Willem de Bruijn <willemb@google.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Kees Cook <kees@kernel.org>
Cc: Simon Horman <horms@kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Will Drewry <wad@chromium.org>, Jeff Layton <jlayton@kernel.org>,
	Jori Koolstra <jkoolstra@xs4all.nl>,
	Oleg Nesterov <oleg@redhat.com>, Andrei Vagin <avagin@gmail.com>,
	Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
	Mateusz Guzik <mjguzik@gmail.com>,
	Joel Granados <joel.granados@kernel.org>,
	Charlie Mirabile <cmirabil@redhat.com>,
	Aleksa Sarai <cyphar@cyphar.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, io-uring@vger.kernel.org
Subject: [RFC PATCH 0/2] net: af_unix: Useful handling of LSM denials on SCM_RIGHTS
Date: Tue, 28 Apr 2026 19:51:23 +0200	[thread overview]
Message-ID: <20260428175125.2705296-1-jkoolstra@xs4all.nl> (raw)

Right now if some LSM such as Smack denies an AF_UNIX socket peer to
receive an SCM_RIGHTS fd the SCM_RIGHTS fd array will be cut short at
that point, and MSG_CTRUNC is set on return of recvmsg(). This is
highly problematic behaviour, because it leaves the receiver
wondering what happened. As per man page MSG_CTRUNC is supposed to
indicate that the control buffer was sized too short, but suddenly
a permission error might result in the exact same flag being set.
Moreover, the receiver has no chance to determine how many fds got
originally sent and how many were suppressed.[1]

Add two MSG_* flags:
 - MSG_RIGHTS_DENIAL is set whenever any file is rejected by the LSM
   during recvmsg(2) of SCM_RIGHTS fds.
 - If MSG_RIGHTS_FILTER is passed as a flag to recvmsg(), the SCM_RIGHTS
   fd array is always passed in its full original size. However, any
   files rejected by the LSM are replaced in this array with -EPERM
   instead of an assigned fd, while keeping the original order. If the
   flag is not set, the original truncate behavior is used.

I am putting this out for RFC for two reasons:

1) The MSG_* space is quite limited. We can do without MSG_RIGHTS_DENIAL 
   if needed.
2) Does userspace ever do anything else than bail out if MSG_CTRUNC is
   found set? If not, we could maybe also get rid of MSG_RIGHTS_FILTER
   and just make this the default behavior.

[1]: https://github.com/uapi-group/kernel-features#useful-handling-of-lsm-denials-on-scm_rights

Jori Koolstra (2):
  net: af_unix: Useful handling of LSM denials on SCM_RIGHTS
  selftest: Add tests for useful handling of LSM denials on SCM_RIGHTS

 fs/file.c                                     |  21 +-
 include/linux/file.h                          |   4 +-
 include/linux/socket.h                        |   3 +
 include/net/scm.h                             |   8 +-
 io_uring/openclose.c                          |   2 +-
 kernel/pid.c                                  |   2 +-
 kernel/seccomp.c                              |   2 +-
 net/compat.c                                  |   7 +-
 net/core/scm.c                                |  11 +-
 .../net/af_unix/lsm_blocking/helper.h         |  37 ++++
 .../net/af_unix/lsm_blocking/receiver.c       | 187 ++++++++++++++++++
 .../net/af_unix/lsm_blocking/sender.c         | 126 ++++++++++++
 .../lsm_blocking/test_scm_rights_smack.sh     | 172 ++++++++++++++++
 13 files changed, 563 insertions(+), 19 deletions(-)
 create mode 100644 tools/testing/selftests/net/af_unix/lsm_blocking/helper.h
 create mode 100644 tools/testing/selftests/net/af_unix/lsm_blocking/receiver.c
 create mode 100644 tools/testing/selftests/net/af_unix/lsm_blocking/sender.c
 create mode 100644 tools/testing/selftests/net/af_unix/lsm_blocking/test_scm_rights_smack.sh

-- 
2.54.0


             reply	other threads:[~2026-04-28 17:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28 17:51 Jori Koolstra [this message]
2026-04-28 17:51 ` [RFC PATCH 1/2] net: af_unix: Useful handling of LSM denials on SCM_RIGHTS Jori Koolstra
2026-04-30  2:04   ` Kuniyuki Iwashima
2026-05-01 15:34     ` Jori Koolstra
2026-05-02  1:24       ` Kuniyuki Iwashima
2026-05-04 17:43         ` Jori Koolstra
2026-04-28 17:51 ` [RFC PATCH 2/2] selftest: Add tests for useful " Jori Koolstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260428175125.2705296-1-jkoolstra@xs4all.nl \
    --to=jkoolstra@xs4all.nl \
    --cc=avagin@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=cmirabil@redhat.com \
    --cc=cyphar@cyphar.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=io-uring@vger.kernel.org \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=joel.granados@kernel.org \
    --cc=kees@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mjguzik@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=pabeni@redhat.com \
    --cc=ptikhomirov@virtuozzo.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wad@chromium.org \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox