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

On Mon, Aug 24, 2026 at 08:36:10AM +0200, Günther Noack wrote:
> 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.
>
From msgget(2):

       A new message queue is created if key has the value IPC_PRIVATE or
       key isn't IPC_PRIVATE, no message queue with the given key key
       exists, and IPC_CREAT is specified in msgflg.

So more specifically, we will disallow if all three of these are true:

- IPC_CREAT is specified
- IPC_PRIVATE is not specified.
- The queue referenced by key does not already exist

Or if these two are true:

- The queue referenced by key already exists.
- The queue referenced by the key is not part of the scope.

Effectively, this allows as much as possible, including msgget(2) on an
existing queue within a scope.

> 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().)
> 
I'll keep this out of the scope for now, but it may be a possible
extension in the future, if a convinving usecase exists.

Each access grant could be an (SYSV_IPC_TYPE, key) tuple that implies
the relevant scope byte.

> ---
> 
> 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
I think that once there are scoped rights for all of the SysV IPC, that
can be examined.

SysV MQ is the oddball one nobody uses. SysV semaphores and shm are much
more popular. But it's important we make all of the SysV IPC rights
consistent with both eachother and the other scoped access rights.

Justin
> 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