From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD3633E4C9F for ; Mon, 24 Aug 2026 06:36:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787553379; cv=none; b=F066p9cPq52hobKBT6U4iNMKK6cNvKaIdIcsNA27tA3JX1FMaTsXhbqhw5SVJOPMiH/bmvSSIm5AO5Kw3xv1ZEqk1KnODgWC2vtXh+W5KAO8zmcZ3TvHpc2H/9c7Azwf3y+HfjMX4gevTz5Oyo2vX36GsqPHThDf1RF7mnYCF04= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787553379; c=relaxed/simple; bh=Fq9KG8uTcVdTd+UsYhiSxgn7mOXWFWafpBMc5Lbpa64=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=elRW7LmcSxakDv6QevzBbZNrOWP3ZNwbYVmxBBMVCJgVZUJdLYf7cBlCr+rjbCxFIgSuAbf+i+26x47uTXmL4S50beR7A5FG2TLWmTKdhcj7GV8PtuaT/hs9azTCbGC4aySU6RTfCyRtYUEQQjtCiWQgqN3ZB0ixyGgB9mun7jQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=eRsAcduN; arc=none smtp.client-ip=209.85.218.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eRsAcduN" Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-c20ce3c118aso580165666b.0 for ; Sun, 23 Aug 2026 23:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787553376; x=1788158176; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=ZPZO/1T9gBfq+o/FMkeYUT9TJ0VTxgJ6DjM2Lc014mU=; b=eRsAcduN1f3oeqENjiwPxmNfEyZgG6NPFKHG2zmv50JNQKWA5FCUiebKcLj6T1ZqY9 sW8ycnUnWb4omZ5aK+GATeSTPSBxlhVL1IBNH2gGBtfuKIMty4eijtLf0/8e3U128oi5 l/8MLhbP9iaattCw4B3elrtWYwuuVsVQpxaNd9JJEw/P4ZAj6UbAgbSVbDIYrnddvZxK mwrrBgpmV3ETQXPAfQuv2r4Qg19aksfwEoCNjYOfs5p/mZqMMXanFZwOco71nJmSRIl7 QzwFA8jcRH0+NRIHiTkknXrj2v/H6cx+3fau+FpQtTBY9nT/9iFtF2MQo2iq6KYDuQTs 1QHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787553376; x=1788158176; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=ZPZO/1T9gBfq+o/FMkeYUT9TJ0VTxgJ6DjM2Lc014mU=; b=LwUQnI3yItljlBl6kMBBPus4o5rk/rD9p6RsuT9L71duc+Bcgk8Da515+g+CCRMpQv W+4Dba7IqnMqPJtvOhlNZ+MFVYLh+P7j46SToGbW2bq3BQDo4vj6gIp6Q7lXBOdeUnqX Ww10urunqy2j23f/jpfcgA3W7/f3rU0NBj1yH0LYP6XcZpgqR/wQkr0xkMvosPLL2xk2 mhcIr+1mZ8Oas7qimo4HbpVZK6gXWHF20ckNyB8pawrviJ9NIGtCy+wAtfGG1mo02CVT CMjfH1DoTOyjwyOiDjiXUcRzJZQnCajk9Bwf1lY0XlRHBpCUuXNQDd9NQB0hv5lrSAOR gOGA== X-Forwarded-Encrypted: i=1; AHgh+Roxd1K6JBIenvQRV8TMmVNzT6bmuogHqBWYTZKKPsgXnPxTR0nTOz9+YntheIbRgKPcL5YSXIerr3G98Qk=@vger.kernel.org X-Gm-Message-State: AFuF++nMePMBcmxykgEAQB68Ma4BLyRnCvZ9Co1NI53foM6B4GVXHJlt 7esoDdVjM9XFNWE+q6zmLs6VDWfdkmk2NbmMABNHjaHUsvnzLG8hH6nJ X-Gm-Gg: AR+sD13U7JDSShwfUi5t9/R3jSDtMN/4kx2PDKQHg2Jl0zkYEt9xHcfWBHyZmzSPy1p 1tP5REGjhA7dnvFyTkZassAR1YD7DdCaYF8caWpcWOuHrdLxZJhoyjYYm1zbzDO39+51dz5lVNo 5rNCBJMtJcAJTocvyt8QVQnYbJAYBMW6cMYJFwR5zxOG+A1WVme7m7HjNuU6EpsRvt62jacoSm0 i3f8u0fFuRHNncTNYnajDwoJmNeACs0haCzBi2JjjKJghtZ2NMlzjnD2K4D7POWTQGw8LYuSg/F I/syFczh2/z+sLmJ80pt2bEKssqzvUqhl5aDK8SyPOT6zfzR9lIF/RU5Ghcz5pae2oHeZAF8AD0 UKOffcv6bEfJu286rgzDMgYTRQSjlFEonH7mgvofIMadte2L93ZNTMK4/KazZ5ZqcjinSgVi6qC JOM4LSbyF/bEt7RDSbs4hkb+oZTqODpHQ6J9b9mED+1HJhcDdeMkChYjCUrP70LhWUGU/YENAjd aJJ75Jai2PB4Q== X-Received: by 2002:a17:907:3e89:b0:c21:7c98:d9ec with SMTP id a640c23a62f3a-c244d6349a2mr2907421166b.5.1787553375916; Sun, 23 Aug 2026 23:36:15 -0700 (PDT) Received: from localhost (ip87-106-108-193.pbiaas.com. [87.106.108.193]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2496738e7esm1210893166b.46.2026.08.23.23.36.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 23:36:15 -0700 (PDT) Date: Mon, 24 Aug 2026 08:36:10 +0200 From: =?iso-8859-1?Q?G=FCnther?= Noack To: Justin Suess Cc: mic@digikod.net, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v2 0/6] landlock: Add scoped access bit for SysV message queues Message-ID: <20260824.abc934a59c55@gnoack.org> References: <20260727230833.138165-1-utilityemal77@gmail.com> <20260822.c9dcabf4999f@gnoack.org> <20260822.3340c3dd2a46@gnoack.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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