Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help test namespace limit for existing profiles #62

Open
igo95862 opened this issue Jul 2, 2023 · 7 comments
Open

Help test namespace limit for existing profiles #62

igo95862 opened this issue Jul 2, 2023 · 7 comments
Labels
help wanted Extra attention is needed

Comments

@igo95862
Copy link
Owner

igo95862 commented Jul 2, 2023

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 igo95862 added the help wanted Extra attention is needed label Jul 2, 2023
@igo95862
Copy link
Owner Author

igo95862 commented Jul 2, 2023

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
Copy link
Contributor

... 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
Copy link
Owner Author

igo95862 commented Jul 2, 2023

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
Copy link
Contributor

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

👍

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
Copy link

xiota commented Oct 26, 2023

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
Copy link
Owner Author

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
Copy link
Owner Author

igo95862 commented Jun 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants