Re: [PATCH v2 0/6] landlock: Add scoped access bit for SysV message queues
From: Justin Suess
Date: Sat Aug 22 2026 - 17:51:50 EST
On Sat, Aug 22, 2026 at 11:13:44PM +0200, Günther Noack wrote:
> On Sat, Aug 22, 2026 at 07:26:33PM +0200, Günther Noack wrote:
> > I get the impression that with this scheme it would be possible for a
> > landlocked process to guess the key of a set of programs which have
> > not created their message queue yet, so that these would then start
> > communicating on that message queue which the sandboxed process has
> > access to.
>
> I realized I did maybe not express that clearly enough: Not only would
> the landlocked process guess the right key, but it would then also
> *create* the queue msgget(key, IPC_CREAT|mode).
>
> There apparently is a pattern in real-world software where the program
> creates the message queue on the fly if it doesn't exist yet, but uses
> the existing queue if it does. Such software is then prone to reuse
> the message queue that was created by the landlocked process. (You
> can find such programs using the Debian code search query from the
> parent mail.)
>
> Step 1: Landlocked program creates message queue.
> Because it creates the queue, it has access to it.
>
> Step 2: Program outside of that domain runs, trying to use the message
> queue. It discovers that the queue already exists and starts
> using it.
>
> Step 3: Landlocked program can read and write the queue and manipulate
> it.
>
I do agree. It's a little harder than unix sockets where we can control
things at the client/server level (no such construct exists for sysv)
It's a little bit tricky. I suppose the easiest way to handle it would
be to deny the ability to squat in a key in the first place. (deny msgget
except with IPC_PRIVATE).
This comes with a cost in functionality, but it is easy to implement and
closes the gap.
Justin
> –Günther
>
> > (Other processes can in principle protect against that by using
> > IPC_CREAT only with IPC_EXCL, but if I understand correctly, it is
> > also a common pattern that communicating processes all simply use
> > msgget() with IPC_CREAT but *without* IPC_EXCL, so that the message
> > queue for them gets created on the fly when first used?)
> >
> > To get a feeling for the number of invocations without IPC_EXCL,
> > compare the number of search results on Debian Code Search for:
> > https://codesearch.debian.net/search?q=msgget%5C%28.*IPC_CREAT&literal=0 (90 results)
> > https://codesearch.debian.net/search?q=msgget%5C%28.*IPC_EXCL&literal=0 (26 results))
> >
> > The construction of the keys is often simple and not built to protect
> > against guessability. ftok() is already somewhat guessable. Some
> > programs even use hardcoded key numbers or invent their own
> > ftok()-like derivation scheme.
> >
> > I do not see how we can prevent the message-queue-squatting situation
> > with the current patch set; It feels like a mistake that we need to
> > analyze what other programs outside the sandbox do, in order to
> > enforce that the sandboxed program can't talk to them.
> >
> > Do you have thoughts on this?
> >
> > > Quirks
> > > ======
> > > - Denials surface as -EACCES rather than -EPERM because the generic
> > > ipcperms() path maps every LSM denial to -EACCES before returning
> > > to userspace. This is documented and the selftests check for
> > > -EACCES accordingly.
> > > - Because there is no persistent handle, a msqid already obtained
> > > by a process before it enforces this scope can become unusable
> > > once the restriction is in place; this is intentional and
> > > documented.
> > >
> > > Patch layout
> > > ============
> > > 1. Add the kern_ipc_perm credential blob and @kind enum.
> > > 2. Implement LANDLOCK_SCOPE_SYSV_MSG_QUEUE, the ipc_permission
> > > hook, and msg_queue_msgctl coverage for IPC_RMID/IPC_SET and
> > > IPC_INFO/MSG_INFO.
> > > 3. Bump the Landlock ABI.
> > > 4. Selftests covering msgget plus a separate fixture for msgsnd,
> > > msgrcv, and msgctl using a pre-created msqid.
> > > 5. sandboxer sample support for the new scope.
> > > 6. Documentation updates covering the new scope, the -EACCES
> > > return code, and the implications of non-persistent handles.
> > >
> > > Test coverage
> > > =============
> > > Selftests exercise denial and allow paths for msgget, msgsnd,
> > > msgrcv, and msgctl(IPC_STAT) across domain boundaries, including
> > > nested-domain inheritance. All existing and added tests are
> > > passing.
> >
> > An audit test would be nice as well; we have one for each possible
> > denial, I think.
> >
> > >
> > > Changes since v1
> > > ================
> > > - Rebased on mic/next.
> > > - Fixed the kernel-doc Return descriptions of hook_ipc_permission()
> > > and hook_msg_queue_msgctl().
> > > - Renamed the internal audit request type to
> > > LANDLOCK_REQUEST_SCOPE_SYSV_MSG_QUEUE for consistency with the
> > > UAPI macro and the "scope.sysv_msg_queue" audit blocker string.
> > > - Integrated the new scope with the sandboxer's quiet access
> > > support added in ABI 10 (new "sysv_msg_queue" LL_QUIET_ACCESS
> > > token).
> > > - Selftests: track the created msqid in the fixture and remove it in
> > > FIXTURE_TEARDOWN_PARENT() so queues are reclaimed even when a failed
> > > assertion aborts a test (and never subject to the scoping under
> > > test); use IPC_PRIVATE where the key is not needed.
> > > - Added CONFIG_SYSVIPC=y to the selftest config fragment.
> > > - Fixed the patch 6 subject typo (LANDLOCK_SCOPE_SYSV_MESSAGE_QUEUE)
> > > and replaced an incorrect ipcperms(3) manpage reference with the
> > > kernel helper ipcperms().
> > > - Reworded the LANDLOCK_SCOPE_SYSV_MSG_QUEUE UAPI comment and the
> > > in-code comment explaining the -EACCES mapping.
> > >
> > > v1: https://lore.kernel.org/all/20260521160640.1716746-1-utilityemal77@xxxxxxxxx/
> > >
> > > Kind Regards,
> > > Justin Suess
> > >
> > > Justin Suess (6):
> > > landlock: Add kern_ipc_perm credential blob structs
> > > landlock: Add LANDLOCK_SCOPE_SYSV_MSG_QUEUE
> > > landlock: Bump ABI for LANDLOCK_SCOPE_SYSV_MSG_QUEUE
> > > selftests/landlock: Test LANDLOCK_SCOPE_SYSV_MSG_QUEUE
> > > samples/landlock: Support LANDLOCK_SCOPE_SYSV_MSG_QUEUE in sandboxer
> > > landlock: Document LANDLOCK_SCOPE_SYSV_MSG_QUEUE
> > >
> > > Documentation/admin-guide/LSM/landlock.rst | 1 +
> > > Documentation/userspace-api/landlock.rst | 30 +-
> > > include/uapi/linux/landlock.h | 4 +
> > > samples/landlock/sandboxer.c | 24 +-
> > > security/landlock/audit.c | 4 +
> > > security/landlock/audit.h | 1 +
> > > security/landlock/limits.h | 2 +-
> > > security/landlock/setup.c | 1 +
> > > security/landlock/syscalls.c | 2 +-
> > > security/landlock/task.c | 137 +++++++++
> > > security/landlock/task.h | 50 ++++
> > > tools/testing/selftests/landlock/base_test.c | 2 +-
> > > tools/testing/selftests/landlock/config | 1 +
> > > .../landlock/scoped_sysv_msg_queue_test.c | 265 ++++++++++++++++++
> > > .../testing/selftests/landlock/scoped_test.c | 2 +-
> > > 15 files changed, 517 insertions(+), 9 deletions(-)
> > > create mode 100644 tools/testing/selftests/landlock/scoped_sysv_msg_queue_test.c
> > >
> > >
> > > base-commit: 28ca6f6f271d47253c240e64cc88a72c89456d74
> > > --
> > > 2.54.0
> > >
> >
> > –Günther