github-starred/firejail
2
0
Fork 0
mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00
Code Issues 531 Projects Packages Wiki Activity Actions 6

[GH-ISSUE #6213] Disable force-nonewprivs on a per-profile basis #3225

New issue
Closed
opened 2026-05-05 09:50:08 -06:00 by gitea-mirror · 10 comments
gitea-mirror commented 2026-05-05 09:50:08 -06:00
Owner
Copy link

Originally created by @ShellCode33 on GitHub (Feb 17, 2024).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6213

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".

Originally created by @ShellCode33 on GitHub (Feb 17, 2024). Original GitHub issue: https://github.com/netblue30/firejail/issues/6213 ### 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".
gitea-mirror 2026-05-05 09:50:08 -06:00
gitea-mirror commented 2026-05-05 09:50:12 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Feb 17, 2024):

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.

<!-- gh-comment-id:1950278933 --> @rusty-snake commented on GitHub (Feb 17, 2024): 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.
gitea-mirror commented 2026-05-05 09:50:12 -06:00
Author
Owner
Copy link

@ShellCode33 commented on GitHub (Feb 17, 2024):

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.

<!-- gh-comment-id:1950280115 --> @ShellCode33 commented on GitHub (Feb 17, 2024): > 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.
gitea-mirror commented 2026-05-05 09:50:13 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Feb 17, 2024):

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.

<!-- gh-comment-id:1950280143 --> @rusty-snake commented on GitHub (Feb 17, 2024): > 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`.
gitea-mirror commented 2026-05-05 09:50:13 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Feb 17, 2024):

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.

And what stops me from running firejail --include=./malicious.include --profile=signal-desktop /usr/bin/vulernable-suid?

<!-- gh-comment-id:1950280493 --> @rusty-snake commented on GitHub (Feb 17, 2024): > 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. And what stops me from running `firejail --include=./malicious.include --profile=signal-desktop /usr/bin/vulernable-suid`?
gitea-mirror commented 2026-05-05 09:50:14 -06:00
Author
Owner
Copy link

@ShellCode33 commented on GitHub (Feb 17, 2024):

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!

<!-- gh-comment-id:1950280980 --> @ShellCode33 commented on GitHub (Feb 17, 2024): > 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!
gitea-mirror commented 2026-05-05 09:50:14 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Feb 17, 2024):

They are, as I use the Linux kernel from GrapheneOS.

OT: It is available for desktop?

<!-- gh-comment-id:1950281492 --> @rusty-snake commented on GitHub (Feb 17, 2024): > They are, as I use the Linux kernel from GrapheneOS. OT: It is available for desktop?
gitea-mirror commented 2026-05-05 09:50:14 -06:00
Author
Owner
Copy link

@ShellCode33 commented on GitHub (Feb 17, 2024):

Yes it is: https://github.com/anthraxx/linux-hardened

If you're running Arch it's as simple as pacman -S linux-hardened

<!-- gh-comment-id:1950281834 --> @ShellCode33 commented on GitHub (Feb 17, 2024): Yes it is: https://github.com/anthraxx/linux-hardened If you're running Arch it's as simple as `pacman -S linux-hardened`
gitea-mirror commented 2026-05-05 09:50:15 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Feb 17, 2024):

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.

<!-- gh-comment-id:1950536728 --> @ghost commented on GitHub (Feb 17, 2024): > 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.
gitea-mirror commented 2026-05-05 09:50:15 -06:00
Author
Owner
Copy link

@ShellCode33 commented on GitHub (Feb 18, 2024):

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)

<!-- gh-comment-id:1950688443 --> @ShellCode33 commented on GitHub (Feb 18, 2024): 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)
gitea-mirror commented 2026-05-05 09:50:15 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Feb 18, 2024):

That's the only difference. Functionality-wise the same sandbox is built for the app to run in.

<!-- gh-comment-id:1950728233 --> @ghost commented on GitHub (Feb 18, 2024): That's the only difference. Functionality-wise the same sandbox is built for the app to run in.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
serialize_remounts_v2
landlock_v4
landlock
release-0.9.64
release-0.9.62
gitlab_ci
LTSbase
fred_ctests
docs
0.9.80
0.9.80-rc1
0.9.78
0.9.76
0.9.76-rc4
0.9.76-rc3
0.9.76-rc2
0.9.76-rc1
0.9.74
landlock-split
0.9.72
0.9.72rc1
0.9.70
0.9.68
0.9.68rc1
0.9.66
0.9.66rc1
0.9.64.4
0.9.64.2
0.9.64
0.9.64rc1
0.9.62.4
0.9.62.2
0.9.62
0.9.56.2-LTS
0.9.60
0.9.60-rc1
0.9.58.2
0.9.58
0.9.58-rc1
0.9.56-LTS-release
0.9.56-LTS
0.9.56
0.9.56-rc1
0.9.54
0.9.54-rc2
0.9.54-rc1
0.9.52
0.9.38.12
0.9.50
0.9.50-rc1
0.9.48
0.9.46
0.9.46-rc1
0.9.44.10
0.9.44.8
0.9.44.6
0.9.38.10
0.9.44.4
0.9.38.8
0.9.44.2
0.9.44
0.9.44-rc1
0.9.38.4
0.9.42
0.9.42-rc2
0.9.38.2
0.9.42-rc1
disable-globalcfg
0.9.40
0.9.40-rc1
0.9.38
0.9.38-rc1
0.9.36
0.9.36-rc1
0.9.34
0.9.34-rc1
0.9.32
0.9.32-rc1
0.9.30
0.9.30-rc1
Labels
Clear labels   
LTS merge

   
LTS merge

   
bug

   
bug

   
converted-to-discussion

   
doc-todo

   
documentation

   
duplicate

   
enhancement

   
file-transfer

   
firecfg

   
firejail-in-firejail

   
firetools

   
graphics

   
help wanted

   
information_old

   
installation

   
invalid

   
modif

   
moved

   
needinfo

   
networking

   
notabug

   
notourbug

   
old-version

   
overlayfs

   
packaging

   
profile-request

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question_old

   
removal

   
runtime-permissions

   
sandbox-ipc

   
security

   
stale

   
wiki

   
wiki

   
wontfix

   
wordpress

   
workaround
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3225
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?