What’s the intended error state for “force-nonewprivs yes” + chromium?

[Foemass]

Hi there,

From reading this: https://firejail.wordpress.com/documentation-2/basic-usage/#suid, I’m aware I shouldn’t be using chromium if I’ve set “force-nonewprivs yes” in /etc/firejail/firejail.config. Which is fair enough.

But I’m wondering what’s meant to happen if I throw all logic to the wind and try it anyway? Because on my current install (with force-nonewprivs set to yes) chromium successfully launches with firejail, appears in firejail --tree, but has unrestricted access to my home folder. Is that intended behavior? I had assumed “force-nonewprivs yes” would just cause fire-jailed chromium to not launch, so I was, perhaps foolishly, trying to use that as an indicator that I’d correctly configured “force-nonewprivs yes”.

I only ask because I just finished a rather convoluted manual install process where I compiled firejail on a different machine and wanted to check I hadn’t accidentally caused some weird undesirable behavior where any program which attempt to rise privileges spontaneously escapes the sandbox.

Anyway, fire-jail is a lovely tool so thanks everyone who’s contributed to it and thank you anyone who entertains my bizarre questions.

Just to clarify for anyone who speed read that, I’m not looking to make chromium work, I understand it shouldn’t with “force-nonewprivs yes”. I’m just wondering what it “not working” looks like for everyone else.

[rusty-snake]

has unrestricted access to my home folder. Is that intended behavior?

How did you check? Did you saw the view of chromium to the filesystem or the filechooser dialog of a portal?

But I’m wondering what’s meant to happen if I throw all logic to the wind and try it anyway?

If unprivileged userns are disable chromium* will not start. If they are enabled everything¹ works fine and you should enable chromium-common-hardened.inc.

¹ with chromium* but other programs like wireshark still break.

and wanted to check I hadn’t accidentally caused some weird undesirable behavior where any program which attempt to rise privileges spontaneously escapes the sandbox.

1. Make sure firejail [ARGS] sudo --help works (i.e. sudo in not blacklisted or disable in other ways like private-bin)
2. Make sure firejail [ARGS] sudo id doesn't work.

[Foemass]

Hi rusty-snake, thanks for your help

How did you check? Did you saw the view of chromium to the filesystem or the filechooser dialog of a portal?

I simply did a right-click save as to save a webpage as a .html file and had full access to all folders in home. Including some that are explicitly blacklisted in globals.local, despite the command line stating that globals.local had been loaded.

you should enable chromium-common-hardened.inc.

I’ve now added include chromium-common-hardened.inc.profile to chromium.local and now it prevents me opening any file explorer with “save as” whatsoever. So that's good. But I still don’t understand why my globals.local restrictions don’t kick in by themselves, or why the default whitelisting in chromuim.profile wasn’t restricting what I can see with save as. The default profile restricts Firefox's access just fine.

If unprivileged userns are disable chromium* will not start. If they are enabled everything¹ works fine and

Sorry, my lack of knowledge is going to show here, just bare with me.

I’m not really sure what you mean by "unprivileged userns". “What is SUID, and how does it affect me” didn’t seem to mention that, only to set up firejail.users (or a firejail group) and set force-nonewprivs yes, which I’ve done. (Which it quite explicitly states not to do if you’re using Chromuim, yet Chromium seems to work fine, hence my confusion XD)

So I guess I must have “unprivileged userns” enabled? How can I check if “unprivileged userns” is disabled or enabled? TBH i'm not even sure if that's a firejail setting or a system setting...

Make sure firejail [ARGS] sudo --help works (i.e. sudo in not blacklisted or disable in other ways like private-bin)

Make sure firejail [ARGS] sudo id doesn't work.

Both of those result in “/bin/bash: /usr/bin/sudo: Permission denied” for me.. Which sounds like a good and desirable thing to my noob understanding. But you're saying this shouldn’t be the case by default with “firejail sudo –help”?

[rusty-snake]

I simply did a right-click save as to save a webpage as a .html file and had full access to all folders in home.

Correct, full access to the home folder. But not the chromium process, only the file-chooser window which is running outside of the sandbox.

I’ve now added include chromium-common-hardened.inc.profile to chromium.local and now it prevents me opening any file explorer with “save as” whatsoever.

So you use KDE?

But I still don’t understand why my globals.local restrictions don’t kick in by themselves, or why the default whitelisting in chromuim.profile wasn’t restricting what I can see with save as.

They kick in. You just checked it "wrong". If you want to see the actual filesystem view of chromium you must use file:https:///home/foemass/.

The default profile restricts Firefox's access just fine.

Because firefox doesn't use portals by default.

So I guess I must have “unprivileged userns” enabled?

Unless you disabled it, use linux-hardened (Arch Linux) or Debian until bookworm(?) it is enabled by default (mainline kernel, Ubuntu, Linux Mint, Fedora Linux, ...)

Both of those result in “/bin/bash: /usr/bin/sudo: Permission denied” for me.. Which sounds like a good and desirable thing to my noob understanding. But you're saying this shouldn’t be the case by default with “firejail sudo –help”?

Yes, to test correctly firejail [--noblacklist='${PATH}/sudo' MORE ARGS] sudo --help must work.

[Foemass]

Correct, full access to the home folder. But not the chromium process, only the file-chooser window which is running outside of the sandbox.

They kick in. You just checked it "wrong". If you want to see the actual filesystem view of chromium you must use file:https:///home/foemass/.

Because firefox doesn't use portals by default.

Ohhhhhhhhhhhhhh! I get it now. Ok I’ve gone back in and tried actually saving the HTML file and can now see it was sandboxed properly from the start, my bad. Thank you for your patience.

So you use KDE?

I use Cinnamon. But presumably blocking that’s covered by chromium-common-hardened.inc.profile too. Not that I really know why an optional “hardended.inc” profile exists for chromium but not anything else XD. But c'est la vie, I don’t use chromium outside of occasionally debugging electron so that's not something I need to understand.

Unless you disabled it, use linux-hardened (Arch Linux) or Debian until bookworm(?) it is enabled by default (mainline kernel, Ubuntu, Linux Mint, Fedora Linux, …)

I’m on Linux Mint, so that explains it then. It sounds like more people then not will have it enabled. So if

1. More people will have privileged userns enabled then not
2. It causes Chromium to work with force-nonewprivs yes

Then perhaps the text for “What is SUID, and how does it affect me?” could do with updating to reflect that you can turn force-nonewprivs on if you use Chromium unless you’re on linux-hardened or have disabled privileged userns. Perhaps I should open an issue for it, what do you think?

On a related note, having privileged userns enabled isn’t some kind of horrific security flaw I should be fixing right? I did do some due diligence before starting out with Linux and this is the first I’m hearing of it, so I sure hope not.

Yes, to test correctly firejail [--noblacklist='${PATH}/sudo' MORE ARGS] sudo --help must work.

firejail --noblacklist='${PATH}/sudo' sudo --help returns “sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set” … is this bad? <.< , >.>

[rusty-snake]

On a related note, having unprivileged userns enabled isn’t some kind of horrific security flaw I should be fixing right?

That's a long discussion if they are good or bad.

IMHO unprivileged userns are good and should always be enabled (that's what mainline kernels do).
The only place where userns should be disabled are inside sandboxes (see #4939).

While I don't agree with PG in a lot points I agree with that:

Note that setting kernel.unprivileged_userns_clone=0 will stop Flatpak, Snap (that depend on browser-sandbox), Electron based AppImages, Podman, Docker, and LXC containers from working. Do not set this flag if you are using container products.

I use Cinnamon.

But maybe the kde portal impls? or an affected gtk/gnome impl? IDK and IDC

(cinnamon has no own impls AFAICTY)

firejail --noblacklist='${PATH}/sudo' sudo --help returns “sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set” … is this bad? <.< , >.>

This sounds good.

[Foemass]

Alright, thanks for all the help! Looks like I'm sorted then. I'll make a separate issue to see if anyone thinks its worth revisiting “What is SUID, and how does it affect me?”, might save someone having to field the same confused series of questions in the future.