find /home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser -executable -type f
List of executable files in Tor Browser folder:
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/start-tor-browser.desktop
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libmozavcodec.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libplds4.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libplc4.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Tor/libssl.so.1.1
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Tor/tor
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Tor/libevent-2.1.so.7
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Tor/libstdc++/libstdc++.so.6
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Tor/libcrypto.so.1.1
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Tor/PluggableTransports/obfs4proxy
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/updater
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libmozsqlite3.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libnss3.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libnssutil3.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/firefox.real
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/start-tor-browser
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/abicheck
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libfreeblpriv3.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/gtk2/libmozgtk.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libmozgtk.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/execdesktop
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libmozsandbox.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/plugin-container
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/start-tor-browser.desktop
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libnssckbi.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libssl3.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libsmime3.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/liblgpllibs.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libnspr4.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libmozavutil.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/firefox
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libxul.so
/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/libsoftokn3.so
Therefore the following is likely creating issues for Tor Browser:
if ! [ "$(stat -c %a "${app_homedir}")" = "700" ]; then
chmod 700 -R "${app_homedir}"
fi
The Tor Browser linux startup script /home/user/.tb/tor-browser/Browser/start-tor-browser is a bit strange. (Same as in original upstream Tor Browser tarball Browser/start-tor-browser.) Please have a look.
By default it logs to a logfile but that is set to /dev/null-
logfile=/dev/null
Therefore we cannot see any debug output from Tor Browser by default.
# If the user hasn't requested 'debug mode' or --help, close stdout and stderr,
# to keep Firefox and the stuff loaded by/for it (including the
# system's shared-library loader) from printing messages to
# $HOME/.xsession-errors or other files. (Users wouldn't have seen
# messages there anyway.)
exec > "$logfile"
exec 2> "$logfile"
The exec is also not pretty because when adding set -x below #!/usr/bin/env bash in Browser/start-tor-browser one cannot see further below the line using exec.
For debugging I am currently running:
sudo bash -x sandbox-app-launcher torbrowser --verbose
It is not specifically verbose. But at least we can see the usual debug output by Firefox which is very useful. Perhaps sandbox-app-launcher should always add --verbose when starting torbrowser? At least for a while during development?
Tor Browser has still some issues? Cannot browse other tabs. Looks like the sandbox is preventing access to something that breaks Tor Browser internal sandbox? Can you fix that please?
+ dbus-launch
+ /home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/start-tor-browser --verbose
Fontconfig warning: "/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown element "blank"
###!!! [Parent][MessageChannel] Error: (msgtype=0x390061,name=PContent::Msg_RefreshScreens) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x390046,name=PContent::Msg_SetXPCOMProcessAttributes) Channel error: cannot send/recv
[Parent 22, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
###!!! [Parent][MessageChannel] Error: (msgtype=0x390036,name=PContent::Msg_UpdateSharedData) Channel error: cannot send/recv
[Parent 22, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
###!!! [Parent][MessageChannel] Error: (msgtype=0x390036,name=PContent::Msg_UpdateSharedData) Channel error: cannot send/recv
[Parent 22, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
###!!! [Parent][MessageChannel] Error: (msgtype=0x39001C,name=PContent::Msg_RegisterChrome) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x390035,name=PContent::Msg_RegisterStringBundles) Channel error: cannot send/recv
[Parent 22, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
###!!! [Parent][MessageChannel] Error: (msgtype=0x39003F,name=PContent::Msg_AppInfo) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x390040,name=PContent::Msg_RemoteType) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x39001A,name=PContent::Msg_PScriptCacheConstructor) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x390051,name=PContent::Msg_LoadProcessScript) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x390051,name=PContent::Msg_LoadProcessScript) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x390051,name=PContent::Msg_LoadProcessScript) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x39000B,name=PContent::Msg_InitRendering) Channel error: cannot send/recv
[Parent 22, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
Sandbox: SandboxBroker: thread creation failed: Resource temporarily unavailable
###!!! [Parent][MessageChannel] Error: (msgtype=0x390050,name=PContent::Msg_Shutdown) Channel error: cannot send/recv
[Parent 22, Gecko_IOThread] WARNING: Failed to launch tab subprocess: file /var/tmp/build/firefox-e01bb643b33f/ipc/glue/GeckoChildProcessHost.cpp, line 745
Sandbox: SandboxBroker: thread creation failed: Resource temporarily unavailable
[Parent 22, Gecko_IOThread] WARNING: Failed to launch tab subprocess: file /var/tmp/build/firefox-e01bb643b33f/ipc/glue/GeckoChildProcessHost.cpp, line 745
[Parent 22, Gecko_IOThread] WARNING: Failed to launch tab subprocess: file /var/tmp/build/firefox-e01bb643b33f/ipc/glue/GeckoChildProcessHost.cpp, line 745
[Parent 22, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
[Parent 22, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
[Parent 22, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /var/tmp/build/firefox-e01bb643b33f/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 19
[Parent 22, Gecko_IOThread] WARNING: Failed to launch tab subprocess: file /var/tmp/build/firefox-e01bb643b33f/ipc/glue/GeckoChildProcessHost.cpp, line 745
[Parent 22, Gecko_IOThread] WARNING: Failed to launch tab subprocess: file /var/tmp/build/firefox-e01bb643b33f/ipc/glue/GeckoChildProcessHost.cpp, line 745
[Parent 22, Gecko_IOThread] WARNING: Failed to launch tab subprocess: file /var/tmp/build/firefox-e01bb643b33f/ipc/glue/GeckoChildProcessHost.cpp, line 745
Fontconfig warning: "/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown element "blank"
Fontconfig warning: "/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown element "blank"
Fontconfig warning: "/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown element "blank"
Fontconfig warning: "/home/sandbox-app-launcher-appdata/torbrowser/.tb/tor-browser/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 85: unknown element "blank"
+ killall -9 -u sandbox-torbrowser
That does not happen with non-sandboxed:
~/.tb/tor-browser/Browser/start-tor-browser --verbose
(Has only this probably unrelated perhaps upstream issue:)
Fontconfig warning: “/home/user/.tb/tor-browser/Browser/TorBrowser/Data/fontconfig/fonts.conf”, line 85: unknown element “blank”
They’re essentially the same. It would probably be better to run dbus-launch manually though for simplicity/compatibility (not all systems would have /etc/X11/Xsession.d/75dbus_dbus-launch and sandbox-app-launcher isn’t just for Debian/X11 systems).
The entire script does not need to be run as root. I think it would be best to split up the setup() and run_program() functions into different command line arguments. So the user would have to run:
sudo sandbox-app-launcher setup app
sandbox-app-launcher run app
The setup part only has to be run once and in most cases can be handled by the hypothetical future apt wrapper or whatever.
The sandboxing code doesn’t actually need to be run as root. bubblewrap is intended for unprivileged usage which is why it is made setuid. The only thing that actually needs root is transitioning to the sandbox users. We could add sudoers exceptions only for switching to the sandbox users and not the entire script.
I don’t see any security issues this way and 99% of potential attack surface is eliminated. A compromised user account would be able to access any app data anyway so there isn’t really any issue in letting it switch users without a password.
There’s also the remaining killall -9 -u "${app_user}" but we can add sudoers exceptions for that too without introducing security issues (killall -9 -u sandbox-example is no different from sudo -u sandbox-example killall ...).
Unrelated but a sandbox-app-launcher uninstall argument would be nice too.
I can’t reproduce this. The internal sandbox shouldn’t even be working currently due to:
But since Firefox is terrible, it lies about the sandbox being active, even in about:support.
What kinds of vulnerabilities does unprivileged user namespace expose?
Can random unprivileged applications just enter a new user namespace as root without hassle and modify firewall settings inside and outside bubblewrap?
Setuid bubblewrap is also a security risk even if user namespace is disabled.
Can I just not disable setuid in bublewrap and disable user namespace in kernel?
Unprivileged user namespaces allow unprivileged users to interact with lots of kernel code that is normally reserved for the root user. It adds a massive amount of networking, mount, etc. functionality as new attack surface. It has been the cause of numerous privilege escalation vulnerabilities which is why many distributions, including Debian have started to disable it by default. The endless stream of vulnerabilities arising from this feature shows no sign of stopping either even after years since its introduction.
Also see:
https://lists.archlinux.org/pipermail/arch-general/2017-February/043066.html
https://lists.archlinux.org/pipermail/arch-general/2017-February/043078.html
User namespaces not used? · Issue #11 · subgraph/oz · GitHub
Inside, yes. Outside, no. User namespaces allow applications to create their own network namespace. Within that network namespace, they can configure their own iptables rules. However, they cannot modify iptables outside of that namespace. This is still an issue because unprivileged users are now exposed to nearly all of the netfilter administration code and can abuse any vulnerability found there.
Setuid binaries are usually a security risk but bubblewrap takes many precautions to ensure that its attack surface is as minimal as possible. It’s essentially just a bare bones wrapper around namespaces and seccomp. There have been very little vulnerabilities ever discovered in it. For example, it doesn’t even support generating seccomp filters - you need to generate your own filter via seccomp_export_bpf and feed it to bubblewrap via a file descriptor. User namespaces are much more of a risk than bubblewrap being setuid.
It needs one or the other for unprivileged usage. If you’re going to only be running it as root i.e. sudo bwrap then it doesn’t matter.
Block access to user namespaces · Issue #368 · containers/bubblewrap · GitHub says
Unprivileged name spaces have a rather smaller attack surface inside bubblewrap, because
NO_NEW_PRIVSshould prevent any attack that relies on (ab)using a setuid executable.
Would firefox and chromium become more vulnerable with setuid than with unprivileged user namespace? They run their own sandboxes.
I’m trying to find the best security configuration for chromium, firefox, bubblewrap, etc, …
Key word is “inside bubblewrap”.
No, user namespaces are more of a risk than a sufficiently audited setuid binary.
But, you wrote unprivileged user namespaces are more dangerous inside bubblewrap.
I didn’t. Inside bubblewrap is not the same as outside.
I want a detailed comparison.
How can random applications exploit unprivileged user namespaces inside bubblewrap?
How can random applications exploit unprivileged user namespaces if they were executed outside bubblewrap?
Inside bubblewrap is a much more restrictive environment than outside so less attack surface is exposed.
GitHub - containers/bubblewrap: Unprivileged sandboxing tool
So, you are saying that unprivileged user namespace increases attack surface inside and outside bubblewrap although bubblewrap reduces attack surface of unprivileged user namespace.
I think I’m going to disable user namespace in my kernel.
Exactly. Inside bubblewrap is just “less bad” although still a problem.
I’d recommend to restrict it to root instead. linux-hardened has a patch that does this:
Depending on your distro, you may have it already.
Various improvements by madaidan · Pull Request #46 · Kicksecure/sandbox-app-launcher · GitHub
This doesn’t add the sudoers exception yet because I’m not sure how to.
Would /etc/sudoers.d/sandbox-app-launcher with the contents:
user ALL=NOPASSWD: /usr/bin/sudo -H -u sandbox-*
suffice? It would require using sudo sudo -H -u sandbox-example but I’m not aware of a better alternative.
We can’t allow all users to do this because having e.g. a compromised sdwdate user being able to access app data isn’t good.
Also, sandbox-example may be too generic. Should we change the prefix to sandbox-app-launcher-example?