Re: Landlock for sandboxing containers

Understood, thanks for the clarifications and the additional information.

I ended up just working around this issue by requiring sessions to be enter=
ed as root explicitly when needed. Thankfully this is no longer so painful =
because recent architectural changes added functionality to easily enter mu=
ltiple sessions on the same running container. So now I've just ditched the=
 sudo binary in the container completely and replaced it with a symlink tha=
t informs the user to enter a new session as root instead. It will be a bit=
 awkward in some situations but seems to be a more secure and simple soluti=
on overall.

This was recently merged in https://github.com/Gerharddc/litterbox/pull/60 =
and will be included in the next release.

Kind regards,
Gerhard

________________________________________
From: Micka=EBl Sala=FCn <[email protected]>
Sent: Friday, March 20, 2026 16:22
To: Gerhard de Clercq <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Landlock for sandboxing containers

On Thu, Mar 12, 2026 at 07:03:38PM +0000, Gerhard de Clercq wrote:
> Thanks for the clarification Micka=EBl!
>
> I've now finally managed to start integrating Landlock into Litterbox at =
https://github.com/Gerharddc/litterbox/blob/landlock/litterbox/src/sandbox.=
rs. Until recently, I did not have a good place for this integration, but n=
ow the Litterbox architecture changed so that a specific binary is always r=
un as the "entrypoint" for a session inside a container. Hence, I can now s=
imply sandbox that binary upon entry.
>
> This seems to work well, but it has broken the ability to run sudo inside=
 the container. To be clear, Litterbox always uses "rootless" containers so=
 this is not the true root user, but it is still nice to have a "virtual" r=
oot user inside the container for added security. What I run into now is th=
e following error:
>
> user@lbx-ubu ~ [SIGSEGV]> sudo apt update
> sudo: The "no new privileges" flag is set, which prevents sudo from runni=
ng as root.
> sudo: If sudo is running in a container, you may need to adjust the conta=
iner configuration to disable the flag.
>
> Is there any way around this or is this a fundamental limitation with Lan=
dlock?

If the process has CAP_SYS_ADMIN it can call landlock_restrict_self()
without no_new_privileges.  This is the exact same check as seccomp
does.  The goal is to avoid privilege escalation via SUID binaries (e.g.
confused deputy attacks).  SUID binaries should not be
available/required in a sandboxed/secured environment because this
mechanism is not consistent with the principle of least privilege.  The
best alternative, if the required feature is really needed, is to rely
on dedicated and secure services (e.g. checking the peer identity)
available through UNIX sockets.

>
> The only workaround I can currently think of would require users to enter=
 a new session explicitly as the root user when needed. This would be very =
awkward compared to just using sudo in an existing session though.

sudo, which is a SUID binary, is also dangerous if reachable by
untrusted processes (see related security vulnerabilities).

Another approach would be to have different execution environments, one
which is not sandboxed (an admin-like environment), and the others which
are properly sandboxed.

We can also think about using things such as SSH but of course this
could also be a way to escape the sandbox.

>
> Kind regards,
> Gerhard
> ________________________________________
> From: Micka=EBl Sala=FCn <[email protected]>
> Sent: Monday, January 19, 2026 12:12
> To: Gerhard de Clercq <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: Re: Landlock for sandboxing containers
>
> On Fri, Jan 16, 2026 at 10:16:28PM +0000, Gerhard de Clercq wrote:
> > Thanks Micka=EBl! Your feedback is much appreciated and should hopefull=
y be enough to get me going now.
> >
> > Just another quick question: how much value do you imagine this combina=
tion (i.e. mount namespaces + Landlock) adds over regular containers (i.e. =
just mount namespaces)? Your paper mentions that namespaces are "designed t=
o create views of the kernel resources, but not to enforce access control p=
olicies". As a non-expert, it is not obvious to me how namespaces can fail =
in the enforcement aspect and it would be great if you could elaborate a bi=
t more on this.
>
> Namespaces are tools used to build containers.  An access control
> doesn't change files layout but it (just) controls access to all
> potential files.  For instance, with only namespaces, a process in a
> container can still access files outside its mount namespaces e.g., with
> passed file descriptors or unexpected (recursive) bind mounts.  It's not
> the role of namespaces to prevent that, it's the role of access control
> systems such as Landlock.  Another thing is that mount points can only
> restrict broad operations (i.e. write and execution), not all kind of
> operations that can be handled by access control systems (e.g., IOCTL,
> file type creation, connection to UNIX socket...).
>
> Namespaces are more complex, require more memory and resources compared
> to Landlock domains/sandboxes.  Landlock is designed to be used by any
> process, even nested in other sandboxes, and malicious processes, which
> is not the case for namespaces.  And because file layout remain the
> same, it's much easier to know what files we are dealing with.
>
> In a nutshell both are complementary, but if you're looking for security
> restrictions, you're looking for an access control system.
>
> >
> > Thanks again for your support and for the awesome project!
>
> Thanks!
>
> >
> > 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 con=
tainer sandboxing utility that I am developing (https://github.com/Gerhardd=
c/litterbox). Essentially Litterbox just makes it easier to setup sandboxed=
 containers for use as reproducible development environments. The idea here=
 is to shield a host system from anything malicious that might show up insi=
de a development environment.
> > >
> > > Since Litterbox is built on Podman, my original plan was to use it's =
built-in support for SELinux policies in conjunction with Udica for policy =
generation. However, since learning about Landlock, it seems that it would =
be much easier to integrate and also more cross-platform (given that SELinu=
x support is rare amongst distros).
> > >
> > > After reading https://landlock.io/talks/2024-06-06_landlock-article.p=
df, Landlock seems very well suited for this purpose. The only thing I am s=
till struggling to wrap my head around is how Landlock integrates with moun=
t namespaces and the implication of that for containers. If I understand co=
rrectly, it is currently not possible to enter a mount namespace after ente=
ring 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 cont=
ainer.
> >
> > 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 exten=
d Podman itself to do so properly since relying on code inside the containe=
r to enter the sandbox on startup seems like something that could easily be=
 attacked.
> >
> > 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 gre=
atly appreciated!
> > >
> > > Kind regards,
> > > Gerhard de Clercq
> >
>