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.

Hm, I have to ponder this; to paraphrase and collect some thoughts:

1. that would make all named (keyed) message queues unreachable,
   because they can only be created outside of a Landlock domain.
2. the ones created with IPC_PRIVATE within the same domain are
   still usable.

I find it hard to construct a realistic scenario in which any
communication would still happen across scope boundaries in that case.

It comes at the expense of not being able to create named (keyed)
message queues within a Landlock domain, which would be potentially
surprising, but I also don't currently see a better way.

(With low confidence): I do wonder whether a landlocked process should
be able to lift that queue-creation restriction if it does it within
an IPC namespace that was created within that Landlock domain?  (It
would complicate the implementation further, and the namespace
interaction would be unusual for a "scoped" access right. Not sure
whether it's worth it.)

It is still possible to guess the msqids within the same IPC
namespace, but the system calls that take a msqid argument will only
work with the ones that were created in the same domain.

Passing a reference to a IPC_PRIVATE queue outwards of a Landlock
domain is possible (e.g. by telling the msgqid number to that process
somehow), and that can establish a communication channel.  This seems
like an unusual way to set that up, but it would be acceptable,
because the outside process would need to collaborate to set it up.
This is in my understanding the only way to establish a cross-scope
communication using a message queue, in your proposal?

Apologies for the brain dump here; I have not fully convinced myself,
but would be interested to hear what you think or whether that seems
correct.

Thanks,
–Günther