Filesystem is root-only readable (user-owned mount namespace)

[WhyNotHugo]

When running something like man via firejail, the path /proc/356611/root is root-owned and only root-readable. My non-root user cannot read this directory at all, even from an unsandboxed process (e.g.: even ls fails).

As far as I understand, / for firejail'd processes is also mounted using root-priviledges (please do correct me if I'm wrong on this item).

Would it be possible to mount this using user namespaces alone? E.g.: Bubblewrap mounts theses filesystems in a way that the unsandboxed user can read from it.

I tried trying to figure out the inner workings of this on Firejail and Bubblewrap, but I'm clearly too unfamiliar with both codebases to figure out enough by myself.

This is remotely related to #5157
I'd also be curious how this would interoperate with flatpak/xdg-desktop-portal#741

[WhyNotHugo]

Oh, I see that the mount call is the same in both bubblewrap and firejail:

firejail/src/firejail/sandbox.c

Line 671 in 9fed798

if (mount(NULL, "/", NULL, MS_SLAVE | MS_REC, NULL) < 0) {

I think the big difference is that the mount operation is being run by a process running as root. I think firejail would need to setuid or change the fsuid before mounting.

[rusty-snake]

Guess which uid the process has that mounts your disk at startup.

The euid a process has while mounting does not change the permissions of the mounted path, mounts and access permissions are two things.

[WhyNotHugo]

Huh, maybe using https://man.archlinux.org/man/setfsuid.2 would fix this?

[rusty-snake]

No it don't.

[glitsj16]

When running something like man via firejail, the path /proc/356611/root is root-owned and only root-readable. My non-root user cannot read this directory at all, even from an unsandboxed process (e.g.: even ls fails).

The unsandboxed man command can read that dir fine on my arch linux box as regular, non-root user. So I'm wondering, how did you test this statement exactly?

$ /usr/bin/man firejail

from another terminal:

$ pidof -s man
78991
$ cat /proc/78991/root/etc/.updated
# This file was created by systemd-update-done. Its only 
# purpose is to hold a timestamp of the time this directory
# was updated. See man:systemd-update-done.service(8).
TIMESTAMP_NSEC=1660559838305943524

[WhyNotHugo]

$ /usr/bin/man firejail

You're not running man via firejail.

> which man
/usr/local/bin/man

> ls -l $(which man)
lrwxrwxrwx 1 root root 17 Aug 14 11:03 /usr/local/bin/man -> /usr/bin/firejail

> man firejail
...

> pidof man
767646

> ls /proc/767646/root
ls: cannot access '/proc/767646/root': Permission denied

[WhyNotHugo]

Unsandboxed processes cannot read this path for sandboxed processed. E.g.: I expect an unsandboxed ls to be able to read /proc/_/root for sandboxed processes. Currently, this is only root-readable.

[rusty-snake]

Answer: #5193 (comment)

[rusty-snake]

See also #5035 and #4623.

And my comment in your issue here: #5062 (comment)

[rusty-snake]

Btw, it's not the filesystem, it's the "symlink" which is "root-only" "readable".

[rusty-snake]

More technical: /proc/<PID>/root can only dereferenced/read by a process that has PTRACE_MODE_READ_FSCREDS ptrace access mode.

[WhyNotHugo]

From #5193:

Various files in /proc/ can not be accessed if the user-ns in which resides is owned by the root user

So the user-ns in which firejail'd processes run is owned by root? Would it be possible for those user-ns to be owned by my local user instead? (again, kinda what bubblewrap does).

[WhyNotHugo]

You mentioned on the linked answer:

Various files in /proc/ can not be accessed if the user-ns in which resides is owned by the root user in the current user-ns (and you are not root). edit: smem relays on /proc//smaps.

I want my current user to be able to access these paths. It seems that this could be fixed by changing firejail so that the user-ns is owned by my current user instead of root. Do you think this is a good idea too? It would possibly improve the situation with flatpak/xdg-desktop-portal#741.

Currently lsns doesn't list namespaces created by firejail. This change should also improve this situation.

[rusty-snake]

Sonebody need to find answers for the following questions:

1. Does this change break anything that requires root owned ns?
2. Is there any security issue with it?

If both are positive we can/should change it.

[WhyNotHugo]

Does this change break anything that requires root owned ns?

I don't think so, but, ultimately, it would need to be tested.

Is there any security issue with it?

Docker/podman/Bubblewrap all create the ns owned by the user, so I'm tempted to say "yes". But this definitely requires further thought.

[WhyNotHugo]

I gave this a quick try to see what breaks:

diff --git a/src/firejail/main.c b/src/firejail/main.c
index c7da3c95c..929f3a6a6 100644
--- a/src/firejail/main.c
+++ b/src/firejail/main.c
@@ -2989,7 +2989,7 @@ int main(int argc, char **argv, char **envp) {
 		errExit("pipe");
 
 	// clone environment
-	int flags = CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWUTS | SIGCHLD;
+	int flags = CLONE_NEWPID | CLONE_NEWUTS | SIGCHLD;
 
 	// in root mode also enable CLONE_NEWIPC
 	// in user mode CLONE_NEWIPC will break MIT Shared Memory Extension (MIT-SHM)
diff --git a/src/firejail/sandbox.c b/src/firejail/sandbox.c
index 9299268a3..f706ba47d 100644
--- a/src/firejail/sandbox.c
+++ b/src/firejail/sandbox.c
@@ -641,6 +641,16 @@ int sandbox(void* sandbox_arg) {
 	// Get rid of unused parameter warning
 	(void)sandbox_arg;
 
+	EUID_USER();
+	if (unshare(CLONE_NEWUSER | CLONE_NEWNS) != 0)
+		errExit("creating user namespace");
+
+	printf("unshare ok\n");
+	EUID_ROOT();
+
 	pid_t child_pid = getpid();
 	if (arg_debug)
 		printf("Initializing child process\n");

This fails very quickly:

> ./src/firejail/firejail --private /usr/bin/bash
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/globals.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 9411, child pid 9412
unshare ok
Mounting tmpfs on /run/firejail/mnt directory
Error mounting /run/firejail/mnt: preproc.c:68 preproc_mount_mnt_dir: Invalid argument
Error: proc 9411 cannot sync with peer: unexpected EOF
Peer 9412 unexpectedly exited with status 1

It seems that the firejail child process needs to hold CAP_SYS_ADMIN in the namespace. I guess the namespace could be created by a separate child with clone, and then using we can switch into it using setns.

Thoughts?

[rusty-snake]

1. You unshare the user-namespace without writing a uid and gid mapping.
2. You try to EUID_ROOT() in a user-namespace created to "remove" the root user.

What did you expected?

[rusty-snake]

What does the EUID_ROOT() return? -1/EPERM I guess.

[WhyNotHugo]

Right, that totally slipped past me. I know at a high level what I'm trying to do, but still discovering the low-level details.

How do I define the uid/gid mapping for the namespace?

[WhyNotHugo]

Okay, so I've failed to implement this -- my C skills aren't good enough for such a task, and I'm also not familiar enough with the low level APIs involved here. I don't think I'll be able to implement this myself, so I'll summarize my thoughts in hopes that someone else can pick this up.

I do still believe this change is very feasible. Basically, instead of creating a new filesystem namespace as root I think firejail should be able to create a new user namespace (as the non-root user calling firejail). The results is essentially a different filesystem namespace which belongs to the current user [on the host].

Because the current user would be able to access /proc/XXX/root, this should allow processes inside firejail containers to talk to the XDG portal (see flatpak/xdg-desktop-portal#680, but the TLDR is that the portal tries to read /proc/XXX/root). This is also a fix for #5318. Of course, dbus filtering will need to be set up for each program, but at least the portal won't outright refuse connections.

Additionally, this would be "one less thing" done by firejail as root. While firejail as a whole still needs to be run as root, it's one less bit of code that runs as root, paving the one to some day potentially not requiring setuid at all.

[rusty-snake]

Linux does not have filesystem namespaces, if you mean mount namespaces, they are not owned by an user, they are owned by an user namespace.

[WhyNotHugo]

s/filesystem namespace/mount namespace/g, e.g.: CLONE_NEWNS, yes.

Various files in /proc/ can not be accessed if the user-ns in which resides is owned by the root user

By "owner" I mean, the this user that you referred to here. The owner is currently root, because the user-ns is owned by root, instead of the current user. Firejail needs to EUID_USER into the user, and then CLONE_NEWUSER | CLONE_NEWNS as the current user.

The current user will then own the user-ns, and be able to read stuff like /proc/XXX/root.

[WhyNotHugo]

Does this makes more sense?