Re: [PATCH v2 0/6] landlock: Add scoped access bit for SysV message queues

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/[email protected]/
> > > 
> > > 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