landlock

[netblue30]

I've just cut a branch for landlock. I'll start re-merging pull request #5315. Stay away from the branch for now, things will break! Will go live in the next release (probably January).

Relates to:

• feature: add Landlock support #6078

[kmk3]

I've just cut a branch for landlock. I'll start re-merging pull request #5315
from @ChrysoliteAzalea. Stay away from the branch for now, things will break!
Will go live in the next release (probably January).

Thanks for using a separate branch for this!

Please open a PR whenever you think it's ready for review, as there were many
fixes/improvements to be done (at least in the original version).

In the PR, I can do these fixes directly in the branch as well if you want.

[netblue30]

Sure, will do! It will be ready to merge in about one week.

[curiosityseeker]

This is certainly exciting news! However, it should be noted that the birdcage project recently removed Landlock:

Remove landlock

This patch completely removes landlock from the Linux sandbox.

While landlock provides solid filesystem isolation even without
requiring any intricate Linux sandboxing knowledge, it is currently
still too limited to build a "bulletproof" filesystem sandbox.

As such, it is better suited for best-effort isolation of "assumed safe"
applications, rather than sandboxing of "potentially hazardous"
software.

So ... is including Landlock possibly a bit pre-mature? Or are the existing Landlock features already worth enough to be added to Firejail?

[rusty-snake]

it is currently still too limited to build a "bulletproof" filesystem sandbox.

Reads as a "landlock alone is to limited" but we combine it with namespaces, seccomp, capabilities, ...

Or are the existing Landlock features already worth enough to be added to Firejail?

That's the question. Depening on how we add it and how/what we expose to profiles. In the following points Landlock is already superior to mount-namespace features:

• Make / noexec and allow exec only for /usr/{lib,lib64,bin,sbin} or even only /usr/{lib,lib64,bin/program,bin/program2}. (And forbid write on those paths to get a W^X filesystem).
• Allow to read and write to files in a directory but not read (list) a directory itself. i.e. ls /etc is forbided, but cat /etc/resolv.conf allowed.
• Allow to write to existing files but not to create new ones.

For stuff like making paths readonly it has no benefit beyond "hey we use Landlock" as long as the fundamental architecture does not change.

[curiosityseeker]

Thanks for this detailed reply! You should know what you're talking about ... 👍

[netblue30]

OK, this is what I have in this moment:

• Compile time detection based on /usr/include/kernel/landlock.h - if the file is present in the filesystem, the feature is compiled in.
• Run-time detection of kernels 6.1 (debian stable) or newer - maybe we can push it down to 5.13, but we need to test it.
• Landlock is the last OS filter applied to the sandbox. All other existing features should work with landlock set on top of them. For example you run "firejail --landlock firefox" and it should work as before.
• The default filesystem set by landlock is very similar to what we have today in apparmor: full system read, some directories read-write, exec only on well-known exec system directories. We are missing some features in the kernel to make it a full replacement for apparmor, but should do it for now. The filesystem code is here: https://github.com/netblue30/firejail/blob/landlock/src/firejail/landlock.c#L189

I think I'll merge it over the weekend.

[rusty-snake]

Run-time detection of kernels 6.1

Why 6.1? Landlock had nothing new in the 6.1 release.

maybe we can push it down to 5.13

We should be able. Landlock is designed with up/downward compatibility and we target ABI version 1 ATM.

Landlock is the last OS filter applied to the sandbox.

I did not looked at the code yet, but seccomp should come after landlock.

For example you run "firejail --landlock firefox" and it should work as before.

Note that reparenting files (move/rename where one of the operates contains a /) is always denied by Landlock in ABI version 1.

[netblue30]

Run-time detection of kernels 6.1

Why 6.1? Landlock had nothing new in the 6.1 release.

I'm on Debian stable, default 6.1 kernel. The previous Debian had a 5.9 kernel, but if we find a machine with a lower kernel number and is working fine, we modify the code to accept that version.

Landlock is the last OS filter applied to the sandbox.

I did not looked at the code yet, but seccomp should come after landlock.

Good point! I'll push it up before seccomp!

For example you run "firejail --landlock firefox" and it should work as before.

Note that reparenting files (move/rename where one of the operates contains a /) is always denied by Landlock in ABI version 1.

Thanks, I'll look into it.

[netblue30]

Note:

Allow to read and write to files in a directory but not read (list) a directory itself. i.e. ls /etc is forbided, but cat /etc/resolv.conf allowed.

I'll put it here so I don't forget about it. We could probably redo some of the --private features using Landlock, and get rid of the previous implementation. For example: --private-etc, --private-bin, private-opt, and private-srv. I think we have in landlock kernel 6.1 everything we need.

[rusty-snake]

Maybe this would even allow use to fix some awkward behaviours of a mount implementation?

but not read (list) a directory itself.

Supplement to this, getdents is covered by landlock and forbidden. Landlock does not cover access/stat yet so you can probe the existence of a file with them (test -e /etc/hosts).

[osevan]

Please dont remove private-etc private-bin and all other private-directory overlay mounts functionality.

Its better have both - old overlayfs AND new landlocked version .

Because present version is already battle tested and works awesome.

Better do it as an additional function Like
Landlocked-etc, landlocked-bin, landlocked-dev, landlocked-usb

And one of most important parts.

landlock "full system path",path2,path3

Separable with ,

And read-write too like landlocked-read-write

And more fine granularity for specific files and folders like read write and execute inside profile.

Thanks and

Best Regards

[rusty-snake]

Please dont remove

No one said remove. "redo ... implementation"

overlayfs

There is no overlayfs in the current implementation.

[kmk3]

@netblue30 on Nov 2:

OK, this is what I have in this moment:

• Compile time detection based on /usr/include/kernel/landlock.h - if the
  file is present in the filesystem, the feature is compiled in.

• Run-time detection of kernels 6.1 (debian stable) or newer - maybe we can
  push it down to 5.13, but we need to test it.

I think I'll merge it over the weekend.

Note that the initial commits in the landlock branch still contain most of
the main issues raised in #5315, especially the readability-related ones.

Also, even though the branch is based on #5315, there is no attribution given
to @ChrysoliteAzalea in the commits.

Merging the branch directly as is would bring those issues in and make
bisecting harder than it needs to be.

Considering the above, I created a landlock_v3 branch based on the landlock
branch. I managed to fix many issues, though it's not quite finished.

Diff comparison between the branches:

• https://github.com/netblue30/firejail/compare/landlock..kmk3:landlock_v3

Note: The diff only shows the code differences between the entire branches, not
the changes in the commits.

[netblue30]

Considering the above, I created a landlock_v3 branch based on the landlock branch. I managed to fix many issues, though it's not quite finished.

Cool! Let's move on your branch. I don't see it under firejail git. How do we do it? Or we can merge landlock_v3 in the existing landlock branch? Any other ideas?

Also, even though the branch is based on #5315, there is no attribution given to @ChrysoliteAzalea in the commits.

We should fix it and give @ChrysoliteAzalea full attribution.

I still have to put the seccomp fix brought up by @rusty-snake, maybe some other small fixes. And any fixes you guys have, just merge them in directly on the branch, and we'll talk about them on this discussion thread.

[kmk3]

@netblue30 on Nov 6:

Considering the above, I created a landlock_v3 branch based on the landlock
branch. I managed to fix many issues, though it's not quite finished.

Cool! Let's move on your branch. I don't see it under firejail git. How do we
do it? Or we can merge landlock_v3 in the existing landlock branch? Any other
ideas?

Ah, I had pushed that one to my user.

Pushed the current version to this repository as landlock_v4; feel free to
commit on it.

Just let me know when you think it's ready for merging; I'd like to edit a few
details beforehand.

Changes compared to the landlock branch:

• https://github.com/netblue30/firejail/compare/landlock..landlock_v4

The main change in the code is that it checks whether landlock is supported at
runtime by using a landlock syscall directly, as recommended by landlock(7).

Also, now if HAVE_LANDLOCK is not defined, empty ll_ functions are defined
instead, to allow calling them outside of landlock.c directly (without ifdefs).

Also, even though the branch is based on #5315, there is no attribution
given to @ChrysoliteAzalea in the commits.

We should fix it and give @ChrysoliteAzalea full attribution.

Added some details to the first/main landlock commit in the branch.

[kmk3]

@netblue30 on Nov 6:

I still have to put the seccomp fix brought up by @rusty-snake, maybe some
other small fixes. And any fixes you guys have, just merge them in directly
on the branch, and we'll talk about them on this discussion thread.

By the way, if there are going to be multiple people committing in the same
branch, everyone please make sure to configure the following:

git config pull.ff only

Then use git pull --rebase when pulling in the branch:

git checkout landlock_v4
git pull # optional, to check if both local/remote branches have extra commits
git pull --rebase

# If there are conflicts, resolve them then run:
git add -u
git rebase --continue

This makes the local landlock_v4 branch be equal to the remote branch plus
the extra local commits on top.

Which prevents merging the branch into itself when pulling and makes
conflict-related issues on pull easier to spot. Example:

# before
A-B-C-D origin/landlock_v4
   \
    E-F landlock_v4

(git pull --rebase) ->

# after
A-B-C-D origin/landlock_v4
       \
        E-F landlock_v4

Also, make sure to not edit (amend/rebase) any commit that was already pushed
to this branch, as that can easily lead to a lot of confusion and conflicts for
whoever else has extra commits on their local branch.

Note: The above is also valid for master.

[netblue30]

Merged on mainline! seccomp fix and some other small issues are coming.

[osevan]

Maybe i didnt understand.
But what was wrong?

Whats the state of landlock inside Firejail?

Which decisions made?

[osevan]

Ok thx.

[osevan]

When im understanding right,

Overlayfs functionality is obsolete with newer kernels and landlock module loading available?

Or is this only addition ?

[rusty-snake]

Overlayfs functionality is obsolete with newer kernels

No, but the current implementation is broken on newer kernels. Also it has known security vulnerabilities. That's why it is disabled.

landlock module loading available

There is no loadable landlock module. See https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html:

The name "module" is a bit of a misnomer since these extensions are not actually loadable kernel modules. Instead, they are selectable at build-time via CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the "security=..." kernel command line argument, in the case where multiple LSMs were built into a given kernel.

[rusty-snake]

Addition to #6065 (reply in thread),

firejail/src/man/firejail.1.in

Lines 3418 to 3458 in 90907ac

	#ifdef HAVE_LANDLOCK
	.SH LANDLOCK
	Landlock is a Linux security module first introduced in version 5.13 of the
	Linux kernel.
	It allows unprivileged processes to restrict their access to the filesystem.
	Once imposed, these restrictions can never be removed, and all child processes
	created by a Landlock-restricted processes inherit these restrictions.
	Firejail supports Landlock as an additional sandboxing feature.
	It can be used to ensure that a sandboxed application can only access files and
	directories that it was explicitly allowed to access.
	Firejail supports populating the ruleset with both a basic set of rules (see
	\fB\-\-landlock\fR) and with a custom set of rules.
	.TP
	Important notes:
	.PP
	.RS
	- A process can install a Landlock ruleset only if it has either
	\fBCAP_SYS_ADMIN\fR in its effective capability set, or the "No New
	Privileges" restriction enabled.
	Because of this, enabling the Landlock feature will also cause Firejail to
	enable the "No New Privileges" restriction, regardless of the profile or the
	\fB\-\-nonewprivs\fR command line option.
	.PP
	- Access to the /proc directory is managed through the \fB\-\-landlock.proc\fR
	command line option.
	.PP
	- Access to the /etc directory is automatically allowed.
	To override this, use the \fB\-\-writable\-etc\fR command line option.
	You can also use the \fB\-\-private\-etc\fR option to restrict access to the
	/etc directory.
	.RE
	.PP
	To enable Landlock self-restriction on top of your current Firejail security
	features, pass \fB\-\-landlock\fR flag to Firejail command line.
	You can also use \fB\-\-landlock.read\fR, \fB\-\-landlock.write\fR,
	\fB\-\-landlock.special\fR and \fB\-\-landlock.execute\fR options together with
	\fB\-\-landlock\fR or instead of it.
	Example:
	.PP
	$ firejail \-\-landlock \-\-landlock.read=/media \-\-landlock.proc=ro mc
	#endif

[rusty-snake]

Second addition, the actual paths for --landlock are

firejail/src/firejail/landlock.c

Lines 210 to 237 in 90907ac

	ll_read("/") || // whole system read
	ll_special("/") || // sockets etc.
	ll_write("/tmp") || // write access
	ll_write("/dev") ||
	ll_write("/run/shm") ||
	ll_write(cfg.homedir) ||
	ll_write(rundir) ||
	ll_exec("/opt") || // exec access
	ll_exec("/bin") ||
	ll_exec("/sbin") ||
	ll_exec("/lib") ||
	ll_exec("/lib32") ||
	ll_exec("/libx32") ||
	ll_exec("/lib64") ||
	ll_exec("/usr/bin") ||
	ll_exec("/usr/sbin") ||
	ll_exec("/usr/games") ||
	ll_exec("/usr/lib") ||
	ll_exec("/usr/lib32") ||
	ll_exec("/usr/libx32") ||
	ll_exec("/usr/lib64") ||
	ll_exec("/usr/local/bin") ||
	ll_exec("/usr/local/sbin") ||
	ll_exec("/usr/local/games") ||
	ll_exec("/usr/local/lib") ||
	ll_exec("/run/firejail"); // appimage and various firejail features

[glitsj16]

networking support for the Landlock security module landed in kernel 6.7:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fff69fb03dde

landlock: Support network rules with TCP bind and connect
Add network rules support in the ruleset management helpers and the
landlock_create_ruleset() syscall. Extend user space API to support
network actions:

• Add new network access rights: LANDLOCK_ACCESS_NET_BIND_TCP and
  LANDLOCK_ACCESS_NET_CONNECT_TCP.
• Add a new network rule type: LANDLOCK_RULE_NET_PORT tied to struct
  landlock_net_port_attr. The allowed_access field contains the network
  access rights, and the port field contains the port value according to
  the controlled protocol. This field can take up to a 64-bit value
  but the maximum value depends on the related protocol (e.g. 16-bit
  value for TCP). Network port is in host endianness [1].
• Add a new handled_access_net field to struct landlock_ruleset_attr
  that contains network access rights.

[rusty-snake]

#6077

Crablock has already support for it, I will test it when Fedora gets 6.7.

[rusty-snake]

Works as expected.

[amano-kenji]

What does landlock do? What does it do for firejail?

[rusty-snake]

What does landlock do?

https://www.man7.org/linux/man-pages/man7/landlock.7.html
https://docs.kernel.org/userspace-api/landlock.html

Trying not to go into technical depths:

• Landlock restricts access to the filesystem _{(ABIv4 can also restrict TCP Sockets)}.
• It is deny-by-default, you can only access files where access was explicitly granted.
• It works tree based e.g. allow /home/user/Downloads means everything under it.
• It is inode (+path_resolution) based rather than path based.
• It is forever, you can not gain access after it got enforce. _{File descriptors received from UNIX Sockets work as expected, permissions are checked during open(2) not read(2)/write(2).}
• Compared to mount-based it has
  • LANDLOCK_ACCESS_FS_EXECUTE which maps to noexec
  • LANDLOCK_ACCESS_FS_MAKE_{CHAR,DIR,REG,SOCK,FIFO,BLOCK,SYM}, LANDLOCK_ACCESS_FS_REMOVE_{DIR,FILE}, LANDLOCK_ACCESS_FS_{WRITE,READ}_FILE which gives much finer control than ro
  • LANDLOCK_ACCESS_FS_READ_DIR which does not have a mount equivalent.
• It still has limitations!

Caution

Not all access kinds (syscalls) are covered yet!

• Metadata is unprotected.
  • You can not hide the existence of a file. (access(2), xyz() -> ENOENT)
  • You can stat(2) every file according to normal permission checks.
  • ...
• ...

My full list: https://codeberg.org/crabjail/crablock/src/commit/58262e3218cfcb76c261e25a8ba497823ff9e1d3/man/crablock.1.in.rst#landlock

What does it do for firejail?

Firejail exposes Landlock ABIv1 based features via --landlock.* commands.

[amano-kenji]

So, is it a linux security module that comes as a C API that can be used by other LSMs?

[rusty-snake]

If the two links above do not help, maybe one of the following links helps:

• https://google.com/
• https://chat.bing.com/

---

C API

syscalls, nevermind

linux security module used by other LSMs

LSM == linux security module

It is an own LSM.

Does any LSM use other LSMs (excluding capability)?

[amano-kenji]

syscalls are C API from my standpoint... in the same way that suicide is a type of death.

Landlock claims to be a stackable LSM.

[rusty-snake]

stackable LSM

https://lwn.net/Articles/804906/

[curiosityseeker]

Thanks, @rusty-snake - that‘s a very nice overview.

Firejail exposes Landlock ABIv1 based features via --landlock.* commands.

Yes, but how will this project proceed? Will landlock only be available as an additional optional hardening measure for the time being? Or will all existing profiles be rewritten to integrate landlock rules?

[rusty-snake]

Or will all existing profiles be rewritten to integrate landlock rules?

Adding include landlock-common.inc to all profiles we can test:

1. Backward compatibility. It increases the required kernel version by 5 years or so.
2. Forward compatibility. Integration of newer Landlock ABIs.
   • Since Landlock is deny-by-default, adding them to landlock-common.inc means to deny more than before.
   • ABIv2: LANDLOCK_ACCESS_FS_REFER. Every program that wants to reparent a file (e.g. rename(2) where oldpath or newpath contains a / and the program has no copy_file_range fallback in case of EXDEV) is not supported by ABIv1.
3. Stricter defaults for landlock-common.inc?
   • Allow the creation of block devices by default?
   • ...
4. --landlock.{read,write} bring them to full power, and allow them on files?

Reimplementing private*, whitelist, ... with Landlock:

• Landlock is not read yet!
• Even crablock has (still under development) mount based sandboxing to be used in addition to Landlock.
  • Mount: Limit the what
  • Landlock: Limit the how _{together with capabilities and seccomp}

[rusty-snake]

More landlock-common.inc improvments:

• Stricter makeipc

  find / -type p 2>/dev/null
  find / -type s 2>/dev/null | sed -E "s;((/[^/]*){3}).*;\1;" | sort -u

• landlock.read /proc is a useless line
• Missing execute for /usr/libexec

[rusty-snake]

Minimal example how a .local override for landlock could look like.

# d-feet.local

landlock.read /usr
landlock.read /proc
ignore landlock.read
ignore landlock.write
ignore landlock.special
include landlock-common.inc

[curiosityseeker]

ignore landlock.read
ignore landlock.write
ignore landlock.special
include landlock-common.inc

Shouldn't this rather be

ignore landlock.read /
ignore landlock.special /

?

[rusty-snake]

No.

• ignore landlock.read / and ignore landlock.read should make no difference (the later will ignore all)
• landlock.special (now splitted into makedev and makeipc) is not required at all. Almost no program needs it.

[curiosityseeker]

* `landlock.read /proc` is a useless line

Because of
landlock.read /

I guess.

[rusty-snake]

Exactly

[curiosityseeker]

* It is forever, you can not gain access after it got enforce. File descriptors received from UNIX Sockets work as expected, permissions are checked during `open(2)` not `read(2)`/`write(2)`.

Huh? What does this precisely mean? Is this really not reversible? Let's say that I added Landlock rules to a *.local profile and comment them later again - what happens?

[rusty-snake]

It means you can not "escape" it via fork(2) or execve(2) because it get inherited and there is no "landlock_unenforce". Just like seccomp(2) or NO_NEW_PRIVS work. Of course nothing that gets enforced by the kernel can live longer than the kernel is running, a reboot will always clear.

[osevan]

https://lore.kernel.org/landlock/20240716.yui4Iezai8ae@digikod.net/T/#u

[osevan]

https://www.phoronix.com/news/Landlock-Restrictions-Bug-Fixed

Can we resrtrict further fork and keyctl syscalls?

[osevan]

Not turn off, but restricting like seccomp.

But ok, when fork can be blocked with seccomp, than seccomp flag inside config file is enough?

Or special flags needed?

[rusty-snake]

Not turn off, but restricting like seccomp.

Turn off in the sandbox.

But ok, when fork can be blocked with seccomp, than seccomp flag inside config file is enough?

You can use seccomp to block syscalls like seccomp socket (block all syscalls in the @default group and socket).

[osevan]

Ok thx

[rusty-snake]

FTR: Note that seccomp fork stops a program from using fork(2) (the syscall not the library function) but is not enough to stop a program from forking.

[rusty-snake]

FTR: --rlimit-nproc= can also be used to limit forking.

[osevan]

https://landlock.io/talks/2024-06-06_landlock-article.pdf

"Ongoing work For now, the main limitations of file access control are
metadata access (e.g., file properties, extended attributes) and file path
probing. However, Landlock can fully control access to file contents. We
are working on extending Landlock’s access control with new rights for
already supported subsystems (i.e. file, TCP), but also to support new
subsystems (e.g., task signaling, sockets, IPCs). 12
Performance and usability improvements are also planned, especially
with path walk access caching, tailored data types, and audit support to
improve debuggability and provide metrics [37]"

[osevan]

https://www.phoronix.com/news/Landlock-Scoping-Unix-Sockets