[GH-ISSUE #3647] webkit2gtk-4.0 requires bwrap #2298

Open
opened 2026-05-05 08:59:02 -06:00 by gitea-mirror · 49 comments
Owner

Originally created by @SkewedZeppelin on GitHub (Sep 27, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3647

The new webkit2gtk-4.0/-2.30 seems to hard require bubblewrap.
This causes firejailed programs such as evolution and epiphany fail to start.
The profiles will need to be updated ala chromium probably.

Edit:
#2995 dropped support for epiphany because of this

Originally created by @SkewedZeppelin on GitHub (Sep 27, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3647 The new webkit2gtk-4.0/-2.30 seems to hard require bubblewrap. This causes firejailed programs such as evolution and epiphany fail to start. The profiles will need to be updated ala chromium probably. Edit: #2995 dropped support for epiphany because of this
Author
Owner

@reinerh commented on GitHub (Sep 27, 2020):

surf is another one using webkitgtk. though after a quick test it was still working in firejail.

<!-- gh-comment-id:699648309 --> @reinerh commented on GitHub (Sep 27, 2020): surf is another one using webkitgtk. though after a quick test it was still working in firejail.
Author
Owner

@rusty-snake commented on GitHub (Sep 27, 2020):

FWIW: https://blogs.gnome.org/mcatanzaro/2020/03/31/sandboxing-webkitgtk-apps/


Fedoras kernel has unprivileged user-ns always enabled. The non-suid bwrap binary which is therefore used as default in Fedora works with these minimal changes:

$ firejail '--noblacklist=${PATH}/bwrap' '--seccomp=!mount,!pivot_root,!umount2' bwrap --dev-bind / / ls

However the suid variant will need more permissions, such as no nonewprivs.

UPDATE: https://github.com/netblue30/firejail/issues/3647#issuecomment-769288256

<!-- gh-comment-id:699650757 --> @rusty-snake commented on GitHub (Sep 27, 2020): FWIW: https://blogs.gnome.org/mcatanzaro/2020/03/31/sandboxing-webkitgtk-apps/ --- Fedoras kernel has unprivileged user-ns always enabled. The non-suid bwrap binary which is therefore used as default in Fedora works with these minimal changes: ``` $ firejail '--noblacklist=${PATH}/bwrap' '--seccomp=!mount,!pivot_root,!umount2' bwrap --dev-bind / / ls ``` However the suid variant will need more permissions, such as no nonewprivs. UPDATE: https://github.com/netblue30/firejail/issues/3647#issuecomment-769288256
Author
Owner

@ckotte commented on GitHub (Oct 8, 2020):

Just adding noblacklist /usr/bin/bwrap works with evolution 3.38 on Arch Linux

Edit: Sorry. I'm wrong.I can start evolution, but new emails cannot be read. I get

bwrap: loopback: Failed to create NETLINK_ROUTE socket: Operation not supported

@rusty-snake How can I put those seccomp and dev-bind options into the profile?

<!-- gh-comment-id:705583014 --> @ckotte commented on GitHub (Oct 8, 2020): Just adding ```noblacklist /usr/bin/bwrap``` works with evolution 3.38 on Arch Linux Edit: Sorry. I'm wrong.I can start evolution, but new emails cannot be read. I get ``` bwrap: loopback: Failed to create NETLINK_ROUTE socket: Operation not supported ``` @rusty-snake How can I put those seccomp and dev-bind options into the profile?
Author
Owner

@rusty-snake commented on GitHub (Oct 9, 2020):

How can I put those seccomp and dev-bind options into the profile?

  1. --dev-bind / / is a bwrap option.
  2. Just create a evolution.local (in e.g. ~/config/firejail) with this content
noblacklist ${PATH}/bwrap
seccomp !mount,!pivot_root,!umount2

However, from the error message you likely need to add protocol unix,inet,inet6,netlink (adding netlink) likewise.

<!-- gh-comment-id:706081283 --> @rusty-snake commented on GitHub (Oct 9, 2020): > How can I put those seccomp and dev-bind options into the profile? 1. `--dev-bind / /` is a bwrap option. 2. Just create a evolution.local (in e.g. ~/config/firejail) with this content ``` noblacklist ${PATH}/bwrap seccomp !mount,!pivot_root,!umount2 ``` However, from the error message you likely need to add `protocol unix,inet,inet6,netlink` (adding `netlink`) likewise.
Author
Owner

@ckotte commented on GitHub (Oct 9, 2020):

Now I get this bwrap: Can't mount proc on /newroot/proc: Operation not permitted. Probably better to not use firejail with evolution anymore..

<!-- gh-comment-id:706104497 --> @ckotte commented on GitHub (Oct 9, 2020): Now I get this ```bwrap: Can't mount proc on /newroot/proc: Operation not permitted```. Probably better to not use firejail with evolution anymore..
Author
Owner

@rusty-snake commented on GitHub (Oct 9, 2020):

Does Arch ship the suid variant? (check ls -l /usr/bin/bwrap)
Does it work with --noprofile? If not we'll need to remove all those programs from firecfg (or make it work).

<!-- gh-comment-id:706267691 --> @rusty-snake commented on GitHub (Oct 9, 2020): Does Arch ship the suid variant? (check `ls -l /usr/bin/bwrap`) Does it work with `--noprofile`? If not we'll need to remove all those programs from firecfg (or make it work).
Author
Owner

@ckotte commented on GitHub (Oct 12, 2020):

Does Arch ship the suid variant? (check ls -l /usr/bin/bwrap)

No suid:

ls -l /usr/bin/bwrap
-rwxr-xr-x 1 root root 55352 Mar 30  2020 /usr/bin/bwrap

Does it work with --noprofile? If not we'll need to remove all those programs from firecfg (or make it work).

Doesn't work with --noprofile. I always get bwrap: Can't mount proc on /newroot/proc: Operation not permitted

<!-- gh-comment-id:707104584 --> @ckotte commented on GitHub (Oct 12, 2020): > Does Arch ship the suid variant? (check `ls -l /usr/bin/bwrap`) No suid: ``` ls -l /usr/bin/bwrap -rwxr-xr-x 1 root root 55352 Mar 30 2020 /usr/bin/bwrap ``` > Does it work with `--noprofile`? If not we'll need to remove all those programs from firecfg (or make it work). Doesn't work with ```--noprofile```. I always get ```bwrap: Can't mount proc on /newroot/proc: Operation not permitted```
Author
Owner

@rusty-snake commented on GitHub (Oct 12, 2020):

Maybe it is caused by the pid-namespace. (If so) we need a option to run the sandbox in the default pid-namespace. Can you post the full bwrap cmd, maybe it only happens if a certain option is used.


Since the are flatpaks for almost every GNOME-App and bwrap does not work inside bwrap, there must be some code which disable the webkit2gtk-4.0 sandbox. Maybe we can trigger this or add a patch to trigger this by a env-var (or there is already one).

<!-- gh-comment-id:707171512 --> @rusty-snake commented on GitHub (Oct 12, 2020): Maybe it is caused by the pid-namespace. (If so) we need a option to run the sandbox in the default pid-namespace. Can you post the full bwrap cmd, maybe it only happens if a certain option is used. ----- Since the are flatpaks for almost every GNOME-App and bwrap does not work inside bwrap, there must be some code which disable the webkit2gtk-4.0 sandbox. Maybe we can trigger this or add a patch to trigger this by a env-var (or there is already one).
Author
Owner

@ckotte commented on GitHub (Oct 12, 2020):

There are two bwrap processes /usr/bin/bwrap --args 58 -- /usr/lib/WebKitWebProcess 7 48 when running without firejail.

I couldn't find a bwrap command in the evolution code. So, not sure how this works.

I also cannot find anything to configure flatpak/bwrap for evolution.

<!-- gh-comment-id:707207961 --> @ckotte commented on GitHub (Oct 12, 2020): There are two bwrap processes ```/usr/bin/bwrap --args 58 -- /usr/lib/WebKitWebProcess 7 48``` when running without firejail. I couldn't find a bwrap command in the evolution code. So, not sure how this works. I also cannot find anything to configure flatpak/bwrap for evolution.
Author
Owner

@rusty-snake commented on GitHub (Oct 13, 2020):

There are two bwrap processes /usr/bin/bwrap --args 58 -- /usr/lib/WebKitWebProcess 7 48 when running without firejail.
I couldn't find a bwrap command in the evolution code. So, not sure how this works.

They pass is via FD 😢 . This bwrap call is in the webkit2gtk code and not in evolution, but I could not find a webkit2gtk repo in the internet.

If flatpak and flathub are configured: flatpak install flathub org.gnome.Evolution

<!-- gh-comment-id:707683470 --> @rusty-snake commented on GitHub (Oct 13, 2020): > There are two bwrap processes /usr/bin/bwrap --args 58 -- /usr/lib/WebKitWebProcess 7 48 when running without firejail. > I couldn't find a bwrap command in the evolution code. So, not sure how this works. They pass is via FD :cry: . This bwrap call is in the webkit2gtk code and not in evolution, but I could not find a webkit2gtk repo in the internet. If flatpak and flathub are configured: `flatpak install flathub org.gnome.Evolution`
Author
Owner

@reinerh commented on GitHub (Oct 13, 2020):

https://sources.debian.org/src/webkit2gtk/2.30.1-1/Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp/?hl=203#L203

if (sandboxEnabled && !isInsideFlatpak() && !isInsideSnap() && !isInsideDocker())
        process = bubblewrapSpawn(launcher.get(), m_launchOptions, argv, &error.outPtr());

Looks like they check for flatpak and other sandboxing already.

<!-- gh-comment-id:707686590 --> @reinerh commented on GitHub (Oct 13, 2020): https://sources.debian.org/src/webkit2gtk/2.30.1-1/Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp/?hl=203#L203 ``` if (sandboxEnabled && !isInsideFlatpak() && !isInsideSnap() && !isInsideDocker()) process = bubblewrapSpawn(launcher.get(), m_launchOptions, argv, &error.outPtr()); ``` Looks like they check for flatpak and other sandboxing already.
Author
Owner

@Micha-Btz commented on GitHub (Nov 21, 2020):

my evolution on debian sid doesn't work. After creating evolution.local with

noblacklist ${PATH}/bwrap
seccomp !mount,!pivot_root,!umount2

evoluition starts, but I'm unable to read a mail, since

Something has gone wrong when displaying the message

A WebKitWebProcess crashed when displaying the message. You can try again by moving to another message and back. If the issue persists, please file a bug report in GNOME Gitlab.

The output from the console shows:

LC_ALL=C firejail --profile=/etc/firejail/evolution.profile /usr/bin/evolution
Reading profile /etc/firejail/evolution.profile
Reading profile /home/mdomann/.config/firejail/evolution.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Warning: networking feature is disabled in Firejail configuration file
Seccomp list in: !mount,!pivot_root,!umount2, check list: @default-keep, prelist: unknown,unknown,unknown,
Parent pid 36121, child pid 36122
Warning: not remounting /home/mdomann/.ssh/authorized_keys
Seccomp list in: !mount,!pivot_root,!umount2, check list: @default-keep, prelist: unknown,unknown,unknown,
Child process initialized in 48.85 ms

(evolution-alarm-notify:23): GLib-GIO-WARNING **: 18:23:06.671: Your application did not unregister from D-Bus before destruction. Consider using g_application_run().
bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.
^[[Obwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.
bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.

(evolution:5): Gtk-WARNING **: 18:23:55.901: Calling org.xfce.Session.Manager.Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Keine derartige Methode ?Inhibit?

(evolution:5): GLib-GIO-WARNING **: 18:23:55.982: Your application did not unregister from D-Bus before destruction. Consider using g_application_run().
^[[I
Parent is shutting down, bye...

I have tested also the newest profile from git hub since it seems to be newer then the debian one, also no success.
Any idea?

Micha

<!-- gh-comment-id:731608661 --> @Micha-Btz commented on GitHub (Nov 21, 2020): my evolution on debian sid doesn't work. After creating evolution.local with > noblacklist ${PATH}/bwrap > seccomp !mount,!pivot_root,!umount2 evoluition starts, but I'm unable to read a mail, since > Something has gone wrong when displaying the message > > A WebKitWebProcess crashed when displaying the message. You can try again by moving to another message and back. If the issue persists, please file a bug report in GNOME Gitlab. The output from the console shows: > LC_ALL=C firejail --profile=/etc/firejail/evolution.profile /usr/bin/evolution > Reading profile /etc/firejail/evolution.profile > Reading profile /home/mdomann/.config/firejail/evolution.local > Reading profile /etc/firejail/disable-common.inc > Reading profile /etc/firejail/disable-devel.inc > Reading profile /etc/firejail/disable-exec.inc > Reading profile /etc/firejail/disable-interpreters.inc > Reading profile /etc/firejail/disable-passwdmgr.inc > Reading profile /etc/firejail/disable-programs.inc > Reading profile /etc/firejail/whitelist-runuser-common.inc > Warning: networking feature is disabled in Firejail configuration file > Seccomp list in: !mount,!pivot_root,!umount2, check list: @default-keep, prelist: unknown,unknown,unknown, > Parent pid 36121, child pid 36122 > Warning: not remounting /home/mdomann/.ssh/authorized_keys > Seccomp list in: !mount,!pivot_root,!umount2, check list: @default-keep, prelist: unknown,unknown,unknown, > Child process initialized in 48.85 ms > > (evolution-alarm-notify:23): GLib-GIO-WARNING **: 18:23:06.671: Your application did not unregister from D-Bus before destruction. Consider using g_application_run(). > bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. > ^[[Obwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. > bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. > > (evolution:5): Gtk-WARNING **: 18:23:55.901: Calling org.xfce.Session.Manager.Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Keine derartige Methode ?Inhibit? > > (evolution:5): GLib-GIO-WARNING **: 18:23:55.982: Your application did not unregister from D-Bus before destruction. Consider using g_application_run(). > ^[[I > Parent is shutting down, bye... I have tested also the newest profile from git hub since it seems to be newer then the debian one, also no success. Any idea? Micha
Author
Owner

@Micha-Btz commented on GitHub (Nov 21, 2020):

Additional question, is firejail needed when bwrap is also a sandbox application?

<!-- gh-comment-id:731608999 --> @Micha-Btz commented on GitHub (Nov 21, 2020): Additional question, is firejail needed when bwrap is also a sandbox application?
Author
Owner

@rusty-snake commented on GitHub (Nov 21, 2020):

my evolution on debian sid

ohh no not debian, this will be even harder. Debian has unprivileged-userns-clones disable and therefore bwrap installed as suid. Either you enable them (sysctl kernel.unprivileged-userns-clone=1) and remove setuid bit from bwarp, or you make it work with firejail. For that you need to remove nonewprivs and likely some more, also you need must not set force-nonewprivs yes in /etc/firejail/firejail.config. But first check that it works with --nopofile (and force-nonewprivs no in firejail.config).

Additional question, is firejail needed when bwrap is also a sandbox application?

Firejail still provides extra security by sandboxing the full application and not parts of it. However, the internal-bwrap sandbox sandboxes the web-content-processes which have a major attack-surfface because they deal with untrusted input. IDK how tight this sandbox is, but those processes usually don't need any filesystem access, so I think they ok. So if you don't want dig deeper, you very likely well protected if you only use the bwrap sandbox for now.

<!-- gh-comment-id:731614468 --> @rusty-snake commented on GitHub (Nov 21, 2020): > my evolution on debian sid ohh no not debian, this will be even harder. Debian has unprivileged-userns-clones disable and therefore bwrap installed as suid. Either you enable them (`sysctl kernel.unprivileged-userns-clone=1`) and remove setuid bit from bwarp, or you make it work with firejail. For that you need to remove `nonewprivs` and likely some more, also you need must not set `force-nonewprivs yes` in /etc/firejail/firejail.config. But first check that it works with `--nopofile` (and `force-nonewprivs no` in firejail.config). > Additional question, is firejail needed when bwrap is also a sandbox application? Firejail still provides extra security by sandboxing the full application and not parts of it. However, the internal-bwrap sandbox sandboxes the web-content-processes which have a major attack-surfface because they deal with untrusted input. IDK how tight this sandbox is, but those processes usually don't need any filesystem access, so I think they ok. So if you don't want dig deeper, you very likely well protected if you only use the bwrap sandbox for now.
Author
Owner

@bbhtt commented on GitHub (Dec 7, 2020):

Can someone confirm if WEBKIT_FORCE_SANDBOX=0 evolution works on Debian?

<!-- gh-comment-id:739634516 --> @bbhtt commented on GitHub (Dec 7, 2020): Can someone confirm if `WEBKIT_FORCE_SANDBOX=0 evolution` works on Debian?
Author
Owner

@rusty-snake commented on GitHub (Jan 28, 2021):

Did a bit strace, here are my findings:

The error occurs only if bwrap is called with --unshare-pid and --proc /proc. So the minimal STR is firejail --noprofile bwrap --unshare-pid --proc /proc --dev-bind / / bash.

mount("proc", "/newroot/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL) = -1 EPERM (Operation not permitted)
<!-- gh-comment-id:769288256 --> @rusty-snake commented on GitHub (Jan 28, 2021): Did a bit strace, here are my findings: The error occurs only if bwrap is called with `--unshare-pid` and `--proc /proc`. So the minimal STR is `firejail --noprofile bwrap --unshare-pid --proc /proc --dev-bind / / bash`. ```C mount("proc", "/newroot/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL) = -1 EPERM (Operation not permitted) ```
Author
Owner

@loveshack commented on GitHub (Aug 25, 2021):

Can someone confirm if WEBKIT_FORCE_SANDBOX=0 evolution works on Debian?

It does, at least to the extent of reading a message, so I've set it in evolution.local.

I'm on Debian 11 with firejail 0.9.66 from the backports repo.
(Unlike on Debian 10, bwrap isn't suid.)

<!-- gh-comment-id:905741800 --> @loveshack commented on GitHub (Aug 25, 2021): > Can someone confirm if `WEBKIT_FORCE_SANDBOX=0 evolution` works on Debian? It does, at least to the extent of reading a message, so I've set it in evolution.local. I'm on Debian 11 with firejail 0.9.66 from the backports repo. (Unlike on Debian 10, bwrap isn't suid.)
Author
Owner

@pedrib commented on GitHub (Oct 1, 2021):

@loveshack can you share your working profile for Debian 11?

I'm not using bwrap (starting with WEBKIT_FORCE_SANDBOX=0 evolution but the built-in firejail profile doesn't work for me with Evolution 3.38.3-1 / firejail 0.9.66:

~ > WEBKIT_FORCE_SANDBOX=0 firejail evolution
Reading profile /etc/firejail/evolution.profile
Reading profile /etc/firejail/globals.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Warning: networking feature is disabled in Firejail configuration file
Warning: Warning: NVIDIA card detected, nogroups command disabled
Warning: noroot option is not available
Parent pid 35144, child pid 35145
Warning: not remounting /home/ble/.ssh/config
Child process initialized in 158.94 ms
Failed to initialize gtk+: Unable to initialize the Clutter backend: no available drivers found.

Parent is shutting down, bye...
<!-- gh-comment-id:932459273 --> @pedrib commented on GitHub (Oct 1, 2021): @loveshack can you share your working profile for Debian 11? I'm not using bwrap (starting with ```WEBKIT_FORCE_SANDBOX=0 evolution``` but the built-in firejail profile doesn't work for me with Evolution 3.38.3-1 / firejail 0.9.66: ``` ~ > WEBKIT_FORCE_SANDBOX=0 firejail evolution Reading profile /etc/firejail/evolution.profile Reading profile /etc/firejail/globals.local Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-devel.inc Reading profile /etc/firejail/disable-exec.inc Reading profile /etc/firejail/disable-interpreters.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/whitelist-runuser-common.inc Warning: networking feature is disabled in Firejail configuration file Warning: Warning: NVIDIA card detected, nogroups command disabled Warning: noroot option is not available Parent pid 35144, child pid 35145 Warning: not remounting /home/ble/.ssh/config Child process initialized in 158.94 ms Failed to initialize gtk+: Unable to initialize the Clutter backend: no available drivers found. Parent is shutting down, bye... ```
Author
Owner

@amano-kenji commented on GitHub (Jul 7, 2022):

caps.keep sys_admin,sys_chroot,net_admin,setuid,setgid,sys_ptrace
ignore caps.drop
ignore nonewprivs
ignore noroot
ignore protocol
ignore seccomp
noblacklist ${PATH}/bwrap
ignore private-bin

This makes bwrap work inside foliate firejail sandbox. bwrap requires

caps.keep sys_admin,sys_chroot,net_admin,setuid,setgid,sys_ptrace

I haven't been able to figure out which binaries need to be passed to private-bin.

<!-- gh-comment-id:1177032853 --> @amano-kenji commented on GitHub (Jul 7, 2022): ``` caps.keep sys_admin,sys_chroot,net_admin,setuid,setgid,sys_ptrace ignore caps.drop ignore nonewprivs ignore noroot ignore protocol ignore seccomp noblacklist ${PATH}/bwrap ignore private-bin ``` This makes bwrap work inside foliate firejail sandbox. bwrap requires > caps.keep sys_admin,sys_chroot,net_admin,setuid,setgid,sys_ptrace I haven't been able to figure out which binaries need to be passed to private-bin.
Author
Owner

@amano-kenji commented on GitHub (Jul 7, 2022):

bwrap requires a lot of capabilities and lack of seccomp. This seems to outweigh benefits of running bwrap inside firejail sandbox.

bdf42ae2bf/source/renderer/gi-gtk.lisp (L30)

nyxt browser just disables webkit sandbox.

7637414ed9/documents/README.org (run-nyxt-in-a-security-sandbox)

nyxt recommends using an external sandbox like guix container or firejail.

<!-- gh-comment-id:1177051039 --> @amano-kenji commented on GitHub (Jul 7, 2022): bwrap requires a lot of capabilities and lack of seccomp. This seems to outweigh benefits of running bwrap inside firejail sandbox. https://github.com/atlas-engineer/nyxt/blob/bdf42ae2bf362143836956179acaf3ea2e32c57d/source/renderer/gi-gtk.lisp#L30 nyxt browser just disables webkit sandbox. https://github.com/atlas-engineer/nyxt/blob/7637414ed9402883647411e108b276ff3889f143/documents/README.org#run-nyxt-in-a-security-sandbox nyxt recommends using an external sandbox like guix container or firejail.
Author
Owner

@sak96 commented on GitHub (Aug 27, 2022):

is there a possibility of getting a feature to set environment variables in profiles ?
this could help manage issue easily.
cc: @rusty-snake

<!-- gh-comment-id:1229230554 --> @sak96 commented on GitHub (Aug 27, 2022): is there a possibility of getting a feature to set environment variables in profiles ? this could help manage issue easily. cc: @rusty-snake
Author
Owner

@reinerh commented on GitHub (Aug 27, 2022):

That is already possible:

       env name=value
              Set environment variable. Examples:
              
              env LD_LIBRARY_PATH=/opt/test/lib
              env CFLAGS="-W -Wall -Werror"
<!-- gh-comment-id:1229231593 --> @reinerh commented on GitHub (Aug 27, 2022): That is already possible: ``` env name=value Set environment variable. Examples: env LD_LIBRARY_PATH=/opt/test/lib env CFLAGS="-W -Wall -Werror" ```
Author
Owner

@sak96 commented on GitHub (Aug 27, 2022):

does that mean this solved the problem for foliate ??

echo env WEBKIT_FORCE_SANDBOX=0   > ~/.config/firejail/foliate.local
<!-- gh-comment-id:1229234194 --> @sak96 commented on GitHub (Aug 27, 2022): does that mean this solved the problem for foliate ?? ```bash echo env WEBKIT_FORCE_SANDBOX=0 > ~/.config/firejail/foliate.local ```
Author
Owner

@reinerh commented on GitHub (Aug 27, 2022):

I don't know. If you have that problem, why don't you try it?

<!-- gh-comment-id:1229234529 --> @reinerh commented on GitHub (Aug 27, 2022): I don't know. If you have that problem, why don't you try it?
Author
Owner

@sak96 commented on GitHub (Aug 27, 2022):

yeah tried it. It works. thanks.

i am just surprised that last time i check i did not fine env in man firejail-profile.
i think i overlooked it.

<!-- gh-comment-id:1229235066 --> @sak96 commented on GitHub (Aug 27, 2022): yeah tried it. It works. thanks. i am just surprised that last time i check i did not fine `env` in `man firejail-profile`. i think i overlooked it.
Author
Owner

@sak96 commented on GitHub (Apr 28, 2023):

10:57:18.571: WEBKIT_FORCE_SANDBOX no longer allows disabling the sandbox. Use WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 instead.

looks like the env variable is changed.

env WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1
<!-- gh-comment-id:1527390238 --> @sak96 commented on GitHub (Apr 28, 2023): > 10:57:18.571: WEBKIT_FORCE_SANDBOX no longer allows disabling the sandbox. Use WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 instead. looks like the env variable is changed. ```firejial env WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 ```
Author
Owner

@amano-kenji commented on GitHub (May 13, 2023):

Should webkit sandbox be disabled? Or, should it be used in firejail?

<!-- gh-comment-id:1546604440 --> @amano-kenji commented on GitHub (May 13, 2023): Should webkit sandbox be disabled? Or, should it be used in firejail?
Author
Owner

@rusty-snake commented on GitHub (May 13, 2023):

You should NOT disable it.

<!-- gh-comment-id:1546608074 --> @rusty-snake commented on GitHub (May 13, 2023): You should NOT disable it.
Author
Owner

@amano-kenji commented on GitHub (May 13, 2023):

I tried to put nyxt with webkit sandbox in firejail sandbox and got this error message.

bwrap: Failed to make / slave: Permission denied
<!-- gh-comment-id:1546611332 --> @amano-kenji commented on GitHub (May 13, 2023): I tried to put nyxt with webkit sandbox in firejail sandbox and got this error message. ``` bwrap: Failed to make / slave: Permission denied ```
Author
Owner

@amano-kenji commented on GitHub (May 15, 2023):

After disabling apparmor, I get this error message.

bwrap: Can't mount proc on /newroot/proc: Operation not permitted

I haven't figured out a way to run a bwrap sandbox inside firejail.

<!-- gh-comment-id:1547128280 --> @amano-kenji commented on GitHub (May 15, 2023): After disabling apparmor, I get this error message. ``` bwrap: Can't mount proc on /newroot/proc: Operation not permitted ``` I haven't figured out a way to run a bwrap sandbox inside firejail.
Author
Owner

@amano-kenji commented on GitHub (Oct 11, 2023):

Has anyone found a way to make bwrap work inside firejail? How does firefox sandbox work inside firejail?

<!-- gh-comment-id:1756853303 --> @amano-kenji commented on GitHub (Oct 11, 2023): Has anyone found a way to make bwrap work inside firejail? How does firefox sandbox work inside firejail?
Author
Owner

@ipaqmaster commented on GitHub (Dec 23, 2023):

Can't seem to get gnome-notes (bijiben) to function with the default firejail enabled. It seems to throw Failed to start dbus proxy: Failed to spawn child process “/usr/bin/bwrap” (No such file or directory).

<!-- gh-comment-id:1868171797 --> @ipaqmaster commented on GitHub (Dec 23, 2023): Can't seem to get gnome-notes (`bijiben`) to function with the default firejail enabled. It seems to throw `Failed to start dbus proxy: Failed to spawn child process “/usr/bin/bwrap” (No such file or directory)`.
Author
Owner

@rusty-snake commented on GitHub (Dec 23, 2023):

Looks linke they updated to gtk-4.

<!-- gh-comment-id:1868242282 --> @rusty-snake commented on GitHub (Dec 23, 2023): Looks linke they updated to gtk-4.
Author
Owner

@amano-kenji commented on GitHub (Jan 24, 2024):

At this point, I think it's better to just disable bwrap with

env WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1

because I could not find a way to make bwrap work inside firejail sandbox. If I had to choose between the two, I would choose firejail because webkit sandbox doesn't place a tight access control over filesystem. The webkit sandbox isn't configurable, either. Firejail sandbox is configurable and tighter.

We can't drag this on for ever. We need something working in a timely manner. I can't wait 3 decades for this issue to be resolved...

<!-- gh-comment-id:1907440621 --> @amano-kenji commented on GitHub (Jan 24, 2024): At this point, I think it's better to just disable bwrap with ``` env WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 ``` because I could not find a way to make bwrap work inside firejail sandbox. If I had to choose between the two, I would choose firejail because webkit sandbox doesn't place a tight access control over filesystem. The webkit sandbox isn't configurable, either. Firejail sandbox is configurable and tighter. We can't drag this on for ever. We need something working in a timely manner. I can't wait 3 decades for this issue to be resolved...
Author
Owner

@rusty-snake commented on GitHub (Jan 24, 2024):

WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1

DON'T DO THIS!

webkit sandbox doesn't place a tight access control over filesystem

This is not true. The code can be found here.

Firejail sandbox is [] tighter.

Heavily depends on the profile.

<!-- gh-comment-id:1908627010 --> @rusty-snake commented on GitHub (Jan 24, 2024): > WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 DON'T DO THIS! > webkit sandbox doesn't place a tight access control over filesystem This is not true. The code can be found [here](https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp). > Firejail sandbox is [] tighter. Heavily depends on the profile.
Author
Owner

@rusty-snake commented on GitHub (Jan 24, 2024):

https://github.com/netblue30/firejail/issues/3647#issuecomment-769288256

Did a bit strace, here are my findings:

The error occurs only if bwrap is called with --unshare-pid and --proc /proc. So the minimal STR is firejail --noprofile bwrap --unshare-pid --proc /proc --dev-bind / / bash.

mount("proc", "/newroot/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL) = -1 EPERM (Operation not permitted)

Doing this with crablock that uses new-mount-api, the fsmount call fails with EPERM. fsopen and fsconfig (including CMD_CREATE) work.

<!-- gh-comment-id:1908687436 --> @rusty-snake commented on GitHub (Jan 24, 2024): https://github.com/netblue30/firejail/issues/3647#issuecomment-769288256 > Did a bit strace, here are my findings: > > The error occurs only if bwrap is called with `--unshare-pid` and `--proc /proc`. So the minimal STR is `firejail --noprofile bwrap --unshare-pid --proc /proc --dev-bind / / bash`. > > ```C > mount("proc", "/newroot/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL) = -1 EPERM (Operation not permitted) > ``` Doing this with crablock that uses new-mount-api, the `fsmount` call fails with `EPERM`. `fsopen` and `fsconfig` (including `CMD_CREATE`) work.
Author
Owner

@rusty-snake commented on GitHub (Jan 24, 2024):

Actually we get a warning in dmesg. 🥳

kernel: VFS: Mount too revealing
<!-- gh-comment-id:1908690655 --> @rusty-snake commented on GitHub (Jan 24, 2024): Actually we get a warning in dmesg. :partying_face: ``` kernel: VFS: Mount too revealing ```
Author
Owner

@rusty-snake commented on GitHub (Jan 24, 2024):

$ firejail --noprofile findmnt
├─/proc                               proc                                                         proc            rw,nosuid,nodev,noexec,relatime
│ ├─/proc/sys/fs/binfmt_misc          systemd-1                                                    autofs          rw,relatime,fd=30,pgrp=0,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9002
│ └─/proc                             proc                                                         proc            rw,nosuid,nodev,noexec,relatime
│   ├─/proc/sysrq-trigger             tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   ├─/proc/sys                       proc[/sys]                                                   proc            ro,nosuid,nodev,noexec,relatime
│   │ ├─/proc/sys/fs/binfmt_misc      tmpfs[/firejail/firejail.ro.dir]                             tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   │ ├─/proc/sys/kernel/core_pattern tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   │ ├─/proc/sys/kernel/modprobe     tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   │ └─/proc/sys/vm/panic_on_oom     tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   ├─/proc/irq                       tmpfs[/firejail/firejail.ro.dir]                             tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   ├─/proc/bus                       tmpfs[/firejail/firejail.ro.dir]                             tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   ├─/proc/timer_list                tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   ├─/proc/kcore                     tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   ├─/proc/kallsyms                  tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64
│   └─/proc/kmsg                      tmpfs[/firejail/firejail.ro.file]                            tmpfs           ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64

What happens if we don't blacklist them?

<!-- gh-comment-id:1908698408 --> @rusty-snake commented on GitHub (Jan 24, 2024): ``` $ firejail --noprofile findmnt ├─/proc proc proc rw,nosuid,nodev,noexec,relatime │ ├─/proc/sys/fs/binfmt_misc systemd-1 autofs rw,relatime,fd=30,pgrp=0,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9002 │ └─/proc proc proc rw,nosuid,nodev,noexec,relatime │ ├─/proc/sysrq-trigger tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ ├─/proc/sys proc[/sys] proc ro,nosuid,nodev,noexec,relatime │ │ ├─/proc/sys/fs/binfmt_misc tmpfs[/firejail/firejail.ro.dir] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ │ ├─/proc/sys/kernel/core_pattern tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ │ ├─/proc/sys/kernel/modprobe tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ │ └─/proc/sys/vm/panic_on_oom tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ ├─/proc/irq tmpfs[/firejail/firejail.ro.dir] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ ├─/proc/bus tmpfs[/firejail/firejail.ro.dir] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ ├─/proc/timer_list tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ ├─/proc/kcore tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ ├─/proc/kallsyms tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 │ └─/proc/kmsg tmpfs[/firejail/firejail.ro.file] tmpfs ro,nosuid,nodev,seclabel,size=1578572k,nr_inodes=819200,mode=755,inode64 ``` What happens if we don't blacklist them?
Author
Owner

@rusty-snake commented on GitHub (Jan 24, 2024):

What happens if we don't blacklist them?

$ firejail --quiet --noprofile bwrap --unshare-pid --proc /proc --dev-bind / / echo "Hello from bubblewrap!"
Hello from bubblewrap
diff
diff --git a/src/firejail/fs.c b/src/firejail/fs.c
index cdad5e220..9f2fcd510 100644
--- a/src/firejail/fs.c
+++ b/src/firejail/fs.c
@@ -718,12 +718,12 @@ void fs_mnt(const int enforce) {
 void fs_proc_sys_dev_boot(void) {
 
 	// remount /proc/sys readonly
-	if (arg_debug)
-		printf("Mounting read-only /proc/sys\n");
-	if (mount("/proc/sys", "/proc/sys", NULL, MS_BIND | MS_REC, NULL) < 0 ||
-	    mount(NULL, "/proc/sys", NULL, MS_BIND | MS_REMOUNT | MS_RDONLY | MS_NOSUID | MS_NOEXEC | MS_NODEV | MS_REC, NULL) < 0)
-		errExit("mounting /proc/sys");
-	fs_logger("read-only /proc/sys");
+	// if (arg_debug)
+	// 	printf("Mounting read-only /proc/sys\n");
+	// if (mount("/proc/sys", "/proc/sys", NULL, MS_BIND | MS_REC, NULL) < 0 ||
+	//     mount(NULL, "/proc/sys", NULL, MS_BIND | MS_REMOUNT | MS_RDONLY | MS_NOSUID | MS_NOEXEC | MS_NODEV | MS_REC, NULL) < 0)
+	// 	errExit("mounting /proc/sys");
+	// fs_logger("read-only /proc/sys");
 
 	/* Mount a version of /sys that describes the network namespace */
 	if (arg_debug)
@@ -753,27 +753,27 @@ void fs_proc_sys_dev_boot(void) {
 	disable_file(BLACKLIST_FILE, "/sys/kernel/uevent_helper");
 
 	// various /proc/sys files
-	disable_file(BLACKLIST_FILE, "/proc/sys/security");
-	disable_file(BLACKLIST_FILE, "/proc/sys/efi/vars");
-	disable_file(BLACKLIST_FILE, "/proc/sys/fs/binfmt_misc");
-	disable_file(BLACKLIST_FILE, "/proc/sys/kernel/core_pattern");
-	disable_file(BLACKLIST_FILE, "/proc/sys/kernel/modprobe");
-	disable_file(BLACKLIST_FILE, "/proc/sysrq-trigger");
-	disable_file(BLACKLIST_FILE, "/proc/sys/kernel/hotplug");
-	disable_file(BLACKLIST_FILE, "/proc/sys/vm/panic_on_oom");
+	// disable_file(BLACKLIST_FILE, "/proc/sys/security");
+	// disable_file(BLACKLIST_FILE, "/proc/sys/efi/vars");
+	// disable_file(BLACKLIST_FILE, "/proc/sys/fs/binfmt_misc");
+	// disable_file(BLACKLIST_FILE, "/proc/sys/kernel/core_pattern");
+	// disable_file(BLACKLIST_FILE, "/proc/sys/kernel/modprobe");
+	// disable_file(BLACKLIST_FILE, "/proc/sysrq-trigger");
+	// disable_file(BLACKLIST_FILE, "/proc/sys/kernel/hotplug");
+	// disable_file(BLACKLIST_FILE, "/proc/sys/vm/panic_on_oom");
 
 	// various /proc files
-	disable_file(BLACKLIST_FILE, "/proc/irq");
-	disable_file(BLACKLIST_FILE, "/proc/bus");
+	// disable_file(BLACKLIST_FILE, "/proc/irq");
+	// disable_file(BLACKLIST_FILE, "/proc/bus");
 	// move /proc/config.gz to disable-common.inc
 	//disable_file(BLACKLIST_FILE, "/proc/config.gz");
-	disable_file(BLACKLIST_FILE, "/proc/sched_debug");
-	disable_file(BLACKLIST_FILE, "/proc/timer_list");
-	disable_file(BLACKLIST_FILE, "/proc/timer_stats");
-	disable_file(BLACKLIST_FILE, "/proc/kcore");
-	disable_file(BLACKLIST_FILE, "/proc/kallsyms");
-	disable_file(BLACKLIST_FILE, "/proc/mem");
-	disable_file(BLACKLIST_FILE, "/proc/kmem");
+	// disable_file(BLACKLIST_FILE, "/proc/sched_debug");
+	// disable_file(BLACKLIST_FILE, "/proc/timer_list");
+	// disable_file(BLACKLIST_FILE, "/proc/timer_stats");
+	// disable_file(BLACKLIST_FILE, "/proc/kcore");
+	// disable_file(BLACKLIST_FILE, "/proc/kallsyms");
+	// disable_file(BLACKLIST_FILE, "/proc/mem");
+	// disable_file(BLACKLIST_FILE, "/proc/kmem");
 
 	// remove kernel symbol information
 	if (!arg_allow_debuggers) {
@@ -818,8 +818,8 @@ void fs_proc_sys_dev_boot(void) {
 
 	if (getuid() != 0) {
 		// disable /dev/kmsg and /proc/kmsg
-		disable_file(BLACKLIST_FILE, "/dev/kmsg");
-		disable_file(BLACKLIST_FILE, "/proc/kmsg");
+		// disable_file(BLACKLIST_FILE, "/dev/kmsg");
+		// disable_file(BLACKLIST_FILE, "/proc/kmsg");
 	}
 
 	EUID_ROOT();
<!-- gh-comment-id:1908744772 --> @rusty-snake commented on GitHub (Jan 24, 2024): > What happens if we don't blacklist them? ```console $ firejail --quiet --noprofile bwrap --unshare-pid --proc /proc --dev-bind / / echo "Hello from bubblewrap!" Hello from bubblewrap ``` <details><summary>diff</summary> ```diff diff --git a/src/firejail/fs.c b/src/firejail/fs.c index cdad5e220..9f2fcd510 100644 --- a/src/firejail/fs.c +++ b/src/firejail/fs.c @@ -718,12 +718,12 @@ void fs_mnt(const int enforce) { void fs_proc_sys_dev_boot(void) { // remount /proc/sys readonly - if (arg_debug) - printf("Mounting read-only /proc/sys\n"); - if (mount("/proc/sys", "/proc/sys", NULL, MS_BIND | MS_REC, NULL) < 0 || - mount(NULL, "/proc/sys", NULL, MS_BIND | MS_REMOUNT | MS_RDONLY | MS_NOSUID | MS_NOEXEC | MS_NODEV | MS_REC, NULL) < 0) - errExit("mounting /proc/sys"); - fs_logger("read-only /proc/sys"); + // if (arg_debug) + // printf("Mounting read-only /proc/sys\n"); + // if (mount("/proc/sys", "/proc/sys", NULL, MS_BIND | MS_REC, NULL) < 0 || + // mount(NULL, "/proc/sys", NULL, MS_BIND | MS_REMOUNT | MS_RDONLY | MS_NOSUID | MS_NOEXEC | MS_NODEV | MS_REC, NULL) < 0) + // errExit("mounting /proc/sys"); + // fs_logger("read-only /proc/sys"); /* Mount a version of /sys that describes the network namespace */ if (arg_debug) @@ -753,27 +753,27 @@ void fs_proc_sys_dev_boot(void) { disable_file(BLACKLIST_FILE, "/sys/kernel/uevent_helper"); // various /proc/sys files - disable_file(BLACKLIST_FILE, "/proc/sys/security"); - disable_file(BLACKLIST_FILE, "/proc/sys/efi/vars"); - disable_file(BLACKLIST_FILE, "/proc/sys/fs/binfmt_misc"); - disable_file(BLACKLIST_FILE, "/proc/sys/kernel/core_pattern"); - disable_file(BLACKLIST_FILE, "/proc/sys/kernel/modprobe"); - disable_file(BLACKLIST_FILE, "/proc/sysrq-trigger"); - disable_file(BLACKLIST_FILE, "/proc/sys/kernel/hotplug"); - disable_file(BLACKLIST_FILE, "/proc/sys/vm/panic_on_oom"); + // disable_file(BLACKLIST_FILE, "/proc/sys/security"); + // disable_file(BLACKLIST_FILE, "/proc/sys/efi/vars"); + // disable_file(BLACKLIST_FILE, "/proc/sys/fs/binfmt_misc"); + // disable_file(BLACKLIST_FILE, "/proc/sys/kernel/core_pattern"); + // disable_file(BLACKLIST_FILE, "/proc/sys/kernel/modprobe"); + // disable_file(BLACKLIST_FILE, "/proc/sysrq-trigger"); + // disable_file(BLACKLIST_FILE, "/proc/sys/kernel/hotplug"); + // disable_file(BLACKLIST_FILE, "/proc/sys/vm/panic_on_oom"); // various /proc files - disable_file(BLACKLIST_FILE, "/proc/irq"); - disable_file(BLACKLIST_FILE, "/proc/bus"); + // disable_file(BLACKLIST_FILE, "/proc/irq"); + // disable_file(BLACKLIST_FILE, "/proc/bus"); // move /proc/config.gz to disable-common.inc //disable_file(BLACKLIST_FILE, "/proc/config.gz"); - disable_file(BLACKLIST_FILE, "/proc/sched_debug"); - disable_file(BLACKLIST_FILE, "/proc/timer_list"); - disable_file(BLACKLIST_FILE, "/proc/timer_stats"); - disable_file(BLACKLIST_FILE, "/proc/kcore"); - disable_file(BLACKLIST_FILE, "/proc/kallsyms"); - disable_file(BLACKLIST_FILE, "/proc/mem"); - disable_file(BLACKLIST_FILE, "/proc/kmem"); + // disable_file(BLACKLIST_FILE, "/proc/sched_debug"); + // disable_file(BLACKLIST_FILE, "/proc/timer_list"); + // disable_file(BLACKLIST_FILE, "/proc/timer_stats"); + // disable_file(BLACKLIST_FILE, "/proc/kcore"); + // disable_file(BLACKLIST_FILE, "/proc/kallsyms"); + // disable_file(BLACKLIST_FILE, "/proc/mem"); + // disable_file(BLACKLIST_FILE, "/proc/kmem"); // remove kernel symbol information if (!arg_allow_debuggers) { @@ -818,8 +818,8 @@ void fs_proc_sys_dev_boot(void) { if (getuid() != 0) { // disable /dev/kmsg and /proc/kmsg - disable_file(BLACKLIST_FILE, "/dev/kmsg"); - disable_file(BLACKLIST_FILE, "/proc/kmsg"); + // disable_file(BLACKLIST_FILE, "/dev/kmsg"); + // disable_file(BLACKLIST_FILE, "/proc/kmsg"); } EUID_ROOT(); ``` </details>
Author
Owner
<!-- gh-comment-id:1908749895 --> @rusty-snake commented on GitHub (Jan 24, 2024): Relevant execution path you have to look at: - https://elixir.bootlin.com/linux/v6.7.1/source/fs/namespace.c#L3931 - https://elixir.bootlin.com/linux/v6.7.1/source/fs/namespace.c#L3987 - https://elixir.bootlin.com/linux/v6.7.1/source/fs/namespace.c#L4888 - https://elixir.bootlin.com/linux/v6.7.1/source/fs/namespace.c#L4908 - https://elixir.bootlin.com/linux/v6.7.1/source/fs/namespace.c#L4819
Author
Owner

@rusty-snake commented on GitHub (Jan 24, 2024):

Btw, crablock mounts with subset=pid by default, so mounting proc would not reveal anything new. Anyway, I think it is ok to check this at fsmount because you could fspick the superblock later on and undo this I think.

<!-- gh-comment-id:1908815338 --> @rusty-snake commented on GitHub (Jan 24, 2024): Btw, crablock mounts with `subset=pid` by default, so mounting `proc` would not reveal anything new. Anyway, I think it is ok to check this at `fsmount` because you could `fspick` the superblock later on and undo this I think.
Author
Owner

@amano-kenji commented on GitHub (Jan 25, 2024):

This is not true. The code can be found here.

Look. I know webkit sandbox cannot be allowed to restrict access to user directories because restricting user access will cause people to ditch web browsers... That's a UX disaster..... Web browsers will be killed if they restricted user access by default.

People will just use another web browser that lets them upload files from any directory without a hassle....

If google chrome pulled off this stunt, it will lose market share to firefox very quickly... Google chrome will die in a month.

With firejail, users choose to restrict user access to a subset of it. With firejail, users have control. With webkit sandbox, users don't get to choose which directories are whitelisted or blacklisted.

I'm not comfortable with a web browser having access to my private files......

<!-- gh-comment-id:1909202826 --> @amano-kenji commented on GitHub (Jan 25, 2024): > This is not true. The code can be found [here](https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp). Look. I know webkit sandbox cannot be allowed to restrict access to user directories because restricting user access will cause people to ditch web browsers... That's a UX disaster..... Web browsers will be killed if they restricted user access by default. People will just use another web browser that lets them upload files from any directory without a hassle.... If google chrome pulled off this stunt, it will lose market share to firefox very quickly... Google chrome will die in a month. With firejail, users choose to restrict user access to a subset of it. With firejail, users have control. With webkit sandbox, users don't get to choose which directories are whitelisted or blacklisted. I'm not comfortable with a web browser having access to my private files......
Author
Owner

@amano-kenji commented on GitHub (Jan 25, 2024):

So, you found a way to make bwrap work inside firejail? Perhaps, can it be packaged as allow-bwrap.inc or something else?

<!-- gh-comment-id:1909516129 --> @amano-kenji commented on GitHub (Jan 25, 2024): So, you found a way to make bwrap work inside firejail? Perhaps, can it be packaged as `allow-bwrap.inc` or something else?
Author
Owner

@rusty-snake commented on GitHub (Jan 25, 2024):

I know webkit sandbox cannot be allowed to restrict access to user directories because restricting user access will cause people to ditch web browsers... That's a UX disaster..... Web browsers will be killed if they restricted user access by default.

  1. If you don't understand the code it's fine, it goes at a very low level in the system. However do not guess what you think it can/must/should do.
  2. The code allows read-only access to a few paths inside homedir: xauth, pulse, sndio, fonts, gtk-theme
  3. You can restrict web contents (webkit) access to homedir while allowing browser access to homedir.
  4. There are different ways you can build a sandbox. You do not need to give it access to any file in homedir if you want upload features. You can have a broker architecture. There are portals.

I'm not comfortable with a web browser having access to my private files......

The webkit process does not have access to all your private files:

$ tree -a /proc/80317/root/home/rusty-snake
/proc/80317/root/home/rusty-snake
├── .cache
│   ├── epiphany
│   │   └── adblock
│   │       ├── 1f353f7cdbb012b9fb1226455f1b3becba42070e1970c1524996fa3a871af406.filterinfo
│   │       └── compiled
│   │           └── ContentRuleList-1f353f7cdbb012b9fb1226455f1b3becba42070e1970c1524996fa3a871af406
│   ├── fontconfig
│   │   ├── 02770245eac059faefae62cb0d56fbcb-le64.cache-8
│   │   ├── 221930ae9526a9cb8049af2916f03412-le64.cache-8
[...]
│   │   ├── c4be257954870c0bf6972134c1de66d5-le64.cache-8
│   │   ├── CACHEDIR.TAG
│   │   ├── cf759820c416606818fc74e5e9991313-le64.cache-8
│   │   ├── d4fe5728f86380c2e3b1e4e9a34fabd8-le64.cache-8
│   │   └── d63f98f14a274bd69a5425fc33aaac6b-le64.cache-8
│   └── mesa_shader_cache
│       └── index
├── .config
│   ├── epiphany
│   ├── gtk-3.0
│   │   └── bookmarks
│   └── pulse
│       └── cookie
└── .local
    └── share
        └── epiphany
            ├── bookmarks.gvdb
            ├── .goutputstream-D05LE1
            ├── .goutputstream-JZ0HE1
            ├── .goutputstream-M25NE1
            ├── .goutputstream-XX5EE1
            ├── .migrated
            ├── page-setup-gtk.ini
            ├── permissions.ini
            ├── print-settings.ini
            └── web_extensions
<!-- gh-comment-id:1910823079 --> @rusty-snake commented on GitHub (Jan 25, 2024): > I know webkit sandbox cannot be allowed to restrict access to user directories because restricting user access will cause people to ditch web browsers... That's a UX disaster..... Web browsers will be killed if they restricted user access by default. 1. If you don't understand the code it's fine, it goes at a very low level in the system. However do not guess what you think it can/must/should do. 2. The code allows read-only access to a few paths inside homedir: xauth, pulse, sndio, fonts, gtk-theme 3. You can restrict web contents (webkit) access to homedir while allowing browser access to homedir. 4. There are different ways you can build a sandbox. You do not need to give it access to any file in homedir if you want upload features. You can have a broker architecture. There are portals. > I'm not comfortable with a web browser having access to my private files...... The webkit process does not have access to all your private files: ``` $ tree -a /proc/80317/root/home/rusty-snake /proc/80317/root/home/rusty-snake ├── .cache │   ├── epiphany │   │   └── adblock │   │   ├── 1f353f7cdbb012b9fb1226455f1b3becba42070e1970c1524996fa3a871af406.filterinfo │   │   └── compiled │   │   └── ContentRuleList-1f353f7cdbb012b9fb1226455f1b3becba42070e1970c1524996fa3a871af406 │   ├── fontconfig │   │   ├── 02770245eac059faefae62cb0d56fbcb-le64.cache-8 │   │   ├── 221930ae9526a9cb8049af2916f03412-le64.cache-8 [...] │   │   ├── c4be257954870c0bf6972134c1de66d5-le64.cache-8 │   │   ├── CACHEDIR.TAG │   │   ├── cf759820c416606818fc74e5e9991313-le64.cache-8 │   │   ├── d4fe5728f86380c2e3b1e4e9a34fabd8-le64.cache-8 │   │   └── d63f98f14a274bd69a5425fc33aaac6b-le64.cache-8 │   └── mesa_shader_cache │   └── index ├── .config │   ├── epiphany │   ├── gtk-3.0 │   │   └── bookmarks │   └── pulse │   └── cookie └── .local └── share └── epiphany ├── bookmarks.gvdb ├── .goutputstream-D05LE1 ├── .goutputstream-JZ0HE1 ├── .goutputstream-M25NE1 ├── .goutputstream-XX5EE1 ├── .migrated ├── page-setup-gtk.ini ├── permissions.ini ├── print-settings.ini └── web_extensions ```
Author
Owner

@rusty-snake commented on GitHub (Jan 25, 2024):

So, you found a way to make bwrap work inside firejail? Perhaps, can it be packaged as allow-bwrap.inc or something else?

It requires code changes. But after that it should be possible with an include allow-bwrap.inc.

<!-- gh-comment-id:1910824564 --> @rusty-snake commented on GitHub (Jan 25, 2024): > So, you found a way to make bwrap work inside firejail? Perhaps, can it be packaged as allow-bwrap.inc or something else? It requires code changes. But after that it should be possible with an `include allow-bwrap.inc`.
Author
Owner

@amano-kenji commented on GitHub (Jan 25, 2024):

You can restrict web contents (webkit) access to homedir while allowing browser access to homedir.

I didn't know that was going on. However, I still want to restrict browser access from my end through firejail or apparmor.

The bloated browser program itself still has user access...

<!-- gh-comment-id:1911157731 --> @amano-kenji commented on GitHub (Jan 25, 2024): > You can restrict web contents (webkit) access to homedir while allowing browser access to homedir. I didn't know that was going on. However, I still want to restrict browser access from my end through firejail or apparmor. The bloated browser program itself still has user access...
Author
Owner

@amano-kenji commented on GitHub (Nov 5, 2024):

Is this issue difficult to solve?

<!-- gh-comment-id:2456226784 --> @amano-kenji commented on GitHub (Nov 5, 2024): Is this issue difficult to solve?
Author
Owner

@rusty-snake commented on GitHub (Nov 5, 2024):

You have to check that allowing the paths in https://github.com/netblue30/firejail/issues/3647#issuecomment-1908744772 can not be abused (e.g. privilege escalation). Then you have to replace them with profile_add and write an allow-bwrap.inc. The difficult part, debugging why it isn't working, is already done.

<!-- gh-comment-id:2456689264 --> @rusty-snake commented on GitHub (Nov 5, 2024): You have to check that allowing the paths in https://github.com/netblue30/firejail/issues/3647#issuecomment-1908744772 can not be abused (e.g. privilege escalation). Then you have to replace them with `profile_add` and write an `allow-bwrap.inc`. The difficult part, debugging why it isn't working, is already done.
Author
Owner

@disposableone commented on GitHub (Feb 9, 2025):

Now I get this bwrap: Can't mount proc on /newroot/proc: Operation not permitted. Probably better to not use firejail with evolution anymore..

I'm getting the same problem with Foliate ebook reader that's using bwrap for webkitgtk6.0. https://github.com/netblue30/firejail/issues/6644

<!-- gh-comment-id:2646303842 --> @disposableone commented on GitHub (Feb 9, 2025): > Now I get this `bwrap: Can't mount proc on /newroot/proc: Operation not permitted`. Probably better to not use firejail with evolution anymore.. I'm getting the same problem with Foliate ebook reader that's using bwrap for webkitgtk6.0. https://github.com/netblue30/firejail/issues/6644
Sign in to join this conversation.
No milestone
No project
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#2298
No description provided.