igo95862 / bubblejail

Bubblewrap based sandboxing for desktop applications
239 stars 16 forks source link

Help test namespace limit for existing profiles #62

Open igo95862 opened 1 year ago

igo95862 commented 1 year ago

Version 0.8.0 has been released with namespace limits service.

Because a lot of applications will fail to run with all namespaces disabled the available profiles had not been given any limits on namespaces. I would like in the next version for profiles to receive a some default namespace limits.

For example, this is a Chromium configuration that I found to work:

[namespaces_limits]
user = 4
mount = 0
pid = -1
ipc = 0
net = 1
time = 0
uts = 0
cgroup = 0

Generally the lsns --tree command should give a good overview on how the application might use namespaces internally.

igo95862 commented 1 year ago

Looks like Firefox will work just fine with all namespaces disabled. However, this stops it from using its own internal sandboxing features where it runs each thread in its own user, ipc and network namespace.

rusty-snake commented 1 year ago

... making it less secure because firefox native sandbox can confine dangerous (web content, ...) processes to a bare minimum of system resources.


The most (user faceing) programs work with all namespaces disabled. Only programs that sandbox them self (chrom*/electron, firefox, newer webkit2gtk) require them.

$ grep -EL "^restrict-namespaces$" $(grep -L "# Redirect" /etc/firejail/*.profile) | wc -l
60
$ grep -El "^restrict-namespaces$" $(grep -L "# Redirect" /etc/firejail/*.profile) | wc -l
580

restrict-namespaces is implemented with seccomp.

igo95862 commented 1 year ago

The advantage of using the /proc/sys/user over the seccomp is that the exact namespace limit can be specified.

For example, it looks like Chromium will only ever use 1 extra network namespace. This means CVE-2023-0179 won't be exploitable since even if the malicious process would be able to spawn user namespaces creating the new network namespace would be impossible.

Looks like Firefox will be able to use sandboxing with this configuration:

[namespaces_limits]
user = -1
mount = 0
pid = 1
ipc = -1
net = -1
time = 0
uts = 0
cgroup = 0

The most (user faceing) programs work with all namespaces disabled.

What about Steam? I think it uses namespaces for its run time implementation.

rusty-snake commented 1 year ago

The advantage of using the /proc/sys/user over the seccomp is that the exact namespace limit can be specified.

:+1:

What about Steam? I think it uses namespaces for its run time implementation.

Steam as a distribution platform has it's own complexity level. It installs and runs games that itself could do a lot. It has some webrendring components.

xiota commented 10 months ago

What is the benefit of limiting namespaces? What is expected to happen when a program, like Firefox, runs out of namespaces? Would Firefox quit working? Stop sandboxing? Something else?

igo95862 commented 10 months ago

What is the benefit of limiting namespaces?

Namespaces are a common vulnerability vector in Linux kernel. See CVE-2023-0179 for example.

Stop sandboxing?

Definitely not. Most often the program would crash.

igo95862 commented 3 months ago

I think I figured out why it namespaces_limits sometimes fail with OSError: [Errno 22] Invalid argument.

For some reason the user namespace fetched from the PID that bubblewrap sends is actually the parent namespace already. This can be fixed with a small check that the subprocess is not already in the owner user namespace.