All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.