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

["Günther Noack" <gnoack3000@gmail.com>]

On Sat, Aug 22, 2026 at 05:51:33PM -0400, Justin Suess wrote:
> 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.

Agreed.  I am personally leaning on the side of closing the gap as
well, even if it reduces functionality somewhat.  SystemV Message
Queues are used very seldomly (as can be seen in Debian Code Search)
and it would affect few programs.

Possible Allow-listing variant
------------------------------

Another possibility that occurred to me after writing the last mail:
One option we could also take here might be to *combine* the scoped
approach and a allow-listing approach, as we have also done it for
named Unix sockets.

In this case that could mean that you would be able to allow-list a
*key*, and then for a msgsnd/msgrcv/msgctl queue operation to be
allowed, it would require that either of these two conditions is
fulfilled:

1. The queue was created in the same Landlock scope (only for IPC_PRIVATE), OR
2. The queue is associated with an allow-listed key

Condition 2 is easy to check because the kernel already tracks the
queue<->key association in struct kern_ipc_perm.

Advantages and Disadvantages:

* It would permit to connect outwards of the scope for allow-listed keys,
  but only within the limits of what the sandbox policy permits.

* For keys generated on the fly as with ftok(), these keys are hard to
  predict up front. (Would have to enforce the policy *after*
  calculating ftok().)

---

Given the limited number of programs that use SystemV message queues
at all, I am unsure whether it is needed to implement that.  But maybe
it would be an interesting thing to keep in mind so that we keep such
an option open in the implementation?  It would at least not rule out
the possibility of restricting SysV message queues in a finer-grained
way.

Let me know what you think.

–Günther