Re: Landlock for sandboxing containers

Thanks Micka=EBl! Your feedback is much appreciated and should hopefully be=
 enough to get me going now.

Just another quick question: how much value do you imagine this combination=
 (i.e. mount namespaces + Landlock) adds over regular containers (i.e. just=
 mount namespaces)? Your paper mentions that namespaces are "designed to cr=
eate views of the kernel resources, but not to enforce access control polic=
ies". As a non-expert, it is not obvious to me how namespaces can fail in t=
he enforcement aspect and it would be great if you could elaborate a bit mo=
re on this.

Thanks again for your support and for the awesome project!

Kind regards,
Gerhard
________________________________________
From: Micka=EBl Sala=FCn <[email protected]>
Sent: Friday, January 16, 2026 15:34
To: Gerhard de Clercq <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Landlock for sandboxing containers

On Thu, Jan 15, 2026 at 09:39:49PM +0000, Gerhard de Clercq wrote:
> Good day,

Hi!

>
> I am investigating the feasibility of integrating Landlock into a contain=
er sandboxing utility that I am developing (https://github.com/Gerharddc/li=
tterbox). Essentially Litterbox just makes it easier to setup sandboxed con=
tainers for use as reproducible development environments. The idea here is =
to shield a host system from anything malicious that might show up inside a=
 development environment.
>
> Since Litterbox is built on Podman, my original plan was to use it's buil=
t-in support for SELinux policies in conjunction with Udica for policy gene=
ration. However, since learning about Landlock, it seems that it would be m=
uch easier to integrate and also more cross-platform (given that SELinux su=
pport is rare amongst distros).
>
> After reading https://landlock.io/talks/2024-06-06_landlock-article.pdf, =
Landlock seems very well suited for this purpose. The only thing I am still=
 struggling to wrap my head around is how Landlock integrates with mount na=
mespaces and the implication of that for containers. If I understand correc=
tly, it is currently not possible to enter a mount namespace after entering=
 a sandbox.

If the sandboxed process has the required capabilities (see setns(2)),
it should be allowed to enter an existing namespace, but not to create
new mounts.  Of course, such capabilities should be dropped as soon as
they are not required.


> Hence, I would somehow enter the sandbox only after entering the containe=
r.

This is indeed the best option: setup the namespaces/cgroups and then
sandbox with Landlock (and seccomp for a more complete isolation).

> Is this understanding correct? If so, I suspect I would need to extend Po=
dman itself to do so properly since relying on code inside the container to=
 enter the sandbox on startup seems like something that could easily be att=
acked.

I would suggest to first wrap the build command with a sandboxer tool
(Island or others, see https://landlock.io/integrations/) and make
Podman launch this wrapper (directly or through an init service).  That
would allow you to quickly iterate and validate that it works as
expected.  If this sandboxer tool and the related configuration cannot
be tampered from within the container, it should be good.

A cleaner but more complex approach would be to patch Podman to do it
more generically and without a wrapper.

>
> Any additional thoughts or suggestions on this endeavour would be greatly=
 appreciated!
>
> Kind regards,
> Gerhard de Clercq