Disable `force-nonewprivs` on a per-profile basis ?
ShellCode33 opened this issue · comments
Is your feature request related to a problem? Please describe.
force-nonewprivs is set to yes in my /etc/firejail/firejail.config but this breaks Electron apps such as signal-desktop which rely on the chromium sandbox setuid binary.
The setuid sandbox is not running as root. Common causes:
* An unprivileged process using ptrace on it, like a debugger.
* A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...)
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
For now I pass --no-sandbox to Electron apps, but it is not ideal.
Describe the solution you'd like
I wish I could leave force-nonewprivs to yes as a default but still allow it on a per-profile basis.
I do realize it would be kind of odd because it wouldn't be "forced" anymore, but I'd like to configure firejail in a way that "what is not explicitly allowed is forbidden".
The hole idea behind force-nonewprivs is that you can not unset it as unprivileged user. This prevents all kinds of vulnerabilities that could happen when suid program is executed in a malicious environment that was created with the privileges of firejail.
The hole idea behind force-nonewprivs is that you can not unset it as unprivileged user.
I do realize that, and that's great.
This prevents all kinds of vulnerabilities that could happen when suid program is executed in a malicious environment that was created with the privileges of firejail
That's precisely why I want force-nonewprivs yes, yet I think it would make sense to provide a way to whitelist some profiles, maybe something like this:
force-nonewprivs yes
allow-newprivs signal-desktop
It would still be something that cannot be unset by an unprivileged user.
For now I pass --no-sandbox to Electron apps, but it is not ideal.
Don't do that.
The Chromium/Electron sandbox is far superior to that of firejail.
this breaks Electron apps such as signal-desktop which rely on the chromium sandbox setuid binary.
Only if unprivileged user namespaces are disabled.
Also this is not limited to nonewprivs. If you rely on the suid sandbox of Chromium, you can not use caps.*, nonewprivs, noroot, protocol, seccomp* or restrict-namespaces.
I'd like to configure firejail in a way that "what is not explicitly allowed is forbidden".
Use globals.local you can deny-by-default much more than you can from firejail.config.
That's precisely why I want
force-nonewprivs yes, yet I think it would make sense to provide a way to whitelist some profiles, maybe something like this:force-nonewprivs yes allow-newprivs signal-desktopIt would still be something that cannot be unset by an unprivileged user.
And what stops me from running firejail --include=./malicious.include --profile=signal-desktop /usr/bin/vulernable-suid?
Only if unprivileged user namespaces are disabled.
They are, as I use the Linux kernel from GrapheneOS.
The Chromium/Electron sandbox is far superior to that of firejail.
Good to know, so maybe I will disable firejail for this profile instead.
Use globals.local you can deny-by-default much more than you can from firejail.config.
But then it doesn't fix the fact that a user can unset it... Maybe that's acceptable in my context though, I will think about it.
And what stops me from running firejail --include=./malicious.include --profile=signal-desktop /usr/bin/vulernable-suid?
Right... I didn't realize that
Thanks for your replies!
They are, as I use the Linux kernel from GrapheneOS.
OT: It is available for desktop?
Yes it is: https://github.com/anthraxx/linux-hardened
If you're running Arch it's as simple as pacman -S linux-hardened
That's precisely why I want force-nonewprivs yes, yet I think it would make sense to provide a way to whitelist some profiles, maybe something like this:
FYI: you could add nonewprivs to a globals.local and simply ignore nonewprivs in those profiles you want to override it. Not a 100% similarity with force-nonewprivs, but (on a single-user machine) close enough IMO.
Works like a charm, thanks ! What are the differences with force-nonewprivs ? (except the fact that it can be overridden by unprivileged users, which is not an issue in my case)
That's the only difference. Functionality-wise the same sandbox is built for the app to run in.