From: "Marek Küthe" <m.k@mk16.de>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: landlock@lists.linux.dev
Subject: Re: Question about using Landlock
Date: Thu, 20 Nov 2025 20:37:45 +0000 [thread overview]
Message-ID: <20251120203745.32463645@ciel> (raw)
In-Reply-To: <20251120.aeC5eePhof6e@digikod.net>
[-- Attachment #1: Type: text/plain, Size: 3205 bytes --]
On Thu, 20 Nov 2025 18:36:50 +0100
Mickaël Salaün <mic@digikod.net> wrote:
> On Wed, Nov 19, 2025 at 09:19:37PM +0000, Marek Küthe wrote:
> > Hello,
>
> Hi!
Thanks for your answers! That answered many of my questions.
> > When accessing the file system, I'm supposed to specify the fd of the
> > file, but then I already have that file open. And that's exactly what
> > Lockland is supposed to control.
>
> The goal of a file descriptor is to identify a file or another kernel
> resource, without race condition, and in an absolute way. It doesn't
> mean it gives access to the underlying resource (but that's the case
> most of the time). With Landlock, it is encouraged to open files with
> O_PATH (see the sandboxer.c example) to avoid leaking opened
> files/access.
>
> Using file paths for kernel interfaces should be avoided.
Could you give an example? I think you mean fd's that don't refer to
anything in the file system?
> Creating files before sandboxing itself can make sense wrt to the threat
> model (i.e. if the potential attacker cannot interact with the process
> at this time). However, you should try to open the tap device before
> the sandboxing and keep the related file descriptor open. This way you
> don't need to bother with the file path of the tap device and you avoid
> other potential issues.
Thanks for the clarification. I'm new to developing "secure programs"
and still need to learn how to create (useful) threat models.
> > 3. Lockland introduces scoped access control starting with ABI 6. To
> > avoid getting warnings from the compiler (and linter), I need to know
> > whether the struct landlock_ruleset_attr has scoped access control or
> > not when programming. Since I only want to support the case where this
> > is true, I would like to check the ABI version at compile time and
> > generate a more meaningful error. How can I check the ABI version at
> > compile time? Is there a macro for this?
>
> Checking the ABI version at build time is not recommended because it
> doesn't give any guarantee about the ABI version at run time. That's
> why the ABI should be a dynamic check.
But I would like to have a build-time guarantee that certain data
structures are available in a certain form or that certain macros
exist. Hence my question about build-time checking.
> > Currently, I am using a check to see if the compiler can compile the
> > struct with `scoped`. [5] However, I don't think this is very elegant.
>
> If the scoped field is defined, then you should use it and update it at
> runtime according to the current Landlock ABI. See the sandboxer.c
> example for such case.
But that assumes that the field exists at build time, and that's
exactly what I want to check.
If I try to initialize a non-existent field, there should be an error
from the compiler (so I want to catch that beforehand). And if I don't
initialize an existing field, clang-tidy complains.
As far as I can tell, sandboxer.c always assumes at build time that it
has been compiled with a new version. Or am I overlooking something?
--
Marek Küthe
m.k@mk16.de
er/ihm he/him
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-11-20 20:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 21:19 Question about using Landlock Marek Küthe
2025-11-20 17:36 ` Mickaël Salaün
2025-11-20 20:37 ` Marek Küthe [this message]
2025-11-21 13:21 ` Mickaël Salaün
2025-11-21 15:14 ` Jeffrey Walton
2025-11-21 15:06 ` Max
2025-12-02 19:02 ` Mickaël Salaün
-- strict thread matches above, loose matches on Subject: below --
2025-11-19 21:27 Marek Küthe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251120203745.32463645@ciel \
--to=m.k@mk16.de \
--cc=landlock@lists.linux.dev \
--cc=mic@digikod.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox