No, I mean moving the Tor Browser files so they’re placed in a standard directory like /usr/bin or something rather than /home.
Running torbrowser within the sandbox will break it since it’s too restrictive. Is there a way to make torbrowser only install the files normally before starting the sandbox and then start the Tor Browser within the sandbox? I.e. separate the installation and execution.
That would probably be difficult, and fragile (with Tor Browser internal updater breaking). If going this route, please create a new forum thread, because that seems rather complex.
Just make sure that folder exists and is writable. Perhaps a test? It would be similar to /home/user.
I.e. HOME=/home/non-existing tb_no_start=true torbrowser would not copy but HOME=/home/existing-user tb_no_start=true torbrowser would work.
As an added bonus if the cached folder /var/cache/tb-binary is not populated for whatever reason it will ask if one wants to download using Tor Browser downloader by Whonix developers.
Please try. Package not available yet but in 1 day or so. Patch should be easy to apply manually though.
Inside the sandbox you can then run torbrowser (/usr/bin/torbrowser) manually since already copied? Otherwise could also use its own startup script but to keep the differences as small as possible the former (/usr/bin/torbrowser) would be preferable. Also /usr/bin/torbrowser has more sanity testing, usability.
(Will require some fine tuning to be compatible with Qubes DispVMs but I can work on that later. Also later on I will see to make sure that /var/cache/tb-binary stays up to date in Non-Qubes-Whonix too. Nothing that would block your development at this point.)
which results in a password required error. However, everything works fine when executing sandbox-app-launcher torbrowser again since it only relies on torbrowser for installation, not execution (I don’t see the need for executing torbrowser within the sandbox, it’ll likely cause more issues).
2) The TOR_SKIP_LAUNCH=1 and other variables are not set which causes errors about the Tor daemon upon launch. I’d imagine stream isolation is also going to be an issue.
I can, and will iron out any issues as far as that is possible. Will look into adding variable to disable remount-exec function now. Please keep letting me know what is causing issues and I will look into fixes. Seems pretty simple on my side of adjusting /usr/bin/torbrowser for this use case, doable quickly.
/usr/bin/torbrowser is not critical but would be useful if that works. Has some usability features:
Yay, tb-starter has now the same skip function feature that tb-updater has. This gives flexibility to skip any function during development (or even final implementation) through setting environment variables.
user.js based solutions are usually breaking after a while due to Tor Browser changes.
Therefore the approach in Whonix is to not do any Tor Browser modifications in the “inside” and only prepare the “outside” so Tor Browser does not have to “know” about anything.
Can we make the anon-ws-disable-stacked-tor approach work inside the sandbox? I.e…
As set in /usr/lib/anon-ws-disable-stacked-tor/torbrowser.sh.
## Environment variable to configure Tor Browser to use a pre existing unix
## domain socket file instead of creating its own one to avoid Tor over Tor and
## to keep it being able to connect.
## systemd-socket-proxyd is being used for creation of unix domain socket file
## /run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock and forwarding it to
## to Whonix-Gateway port 9150.
## https://phabricator.whonix.org/T192
## https://trac.torproject.org/projects/tor/ticket/20111#comment:5
export TOR_SOCKS_IPC_PATH="/run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock"
export TOR_CONTROL_IPC_PATH="/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock"
I.e. is it sane and possible for the sandbox to allow access to files:
The only remaining issue is that it doesn’t execute torbrowser but rather the start-tor-browser script. Executing torbrowser inside the sandbox doesn’t work. I will investigate it further but this should be ok for now.
I will also silent tb-starter copying Tor Browser with --verbose. (It is bad practice for wrappers to introduce extraneous console output since that could break other wrappers (custom, written by users) which parse these program’s output.)
You can use the network from within the namespace but only if you set it up prior. We use empty net namespaces for allow_net=no so no networking should be possible at all without a kernel exploit.
We could also expand allow_net to blacklist network-related syscalls in addition to the network namespace but this seems redundant.
Lost track of that one. Thanks for reminding me. Now merged.
One that one, I’ve added -q to grep, i.e. now grep -q.
And changed userdel "${user}" to userdel "${user}" || true. userdel might fail? Not sure. But if it ever does, it is probably not worth “breaking APT” for that?
Wiki page (or readme) could use some information: how dbus, audio and X11 (did I miss something else important?) is currently handled, potentially future enhancements.
WARNING: There are several unresolved issues that affect security and
fingerprinting. Do not assume that this is perfect, merely “an improvement over nothing”.
It’s not really comparable. That sandbox is designed/fine-tuned for a single application. sandbox-app-launcher is a generic, “catch-all” sandbox.
I don’t see how sandbox-app-launcher could affect fingerprinting. Websites don’t have direct access to files, syscalls, etc. They can’t detect whether the browser is sandboxed.
There are security issues of course. The main one being X11 but hopefully we can switch to Wayland.
I assume they made as much as possible read-only. This wouldn’t really make sense for sandbox-app-launcher since it isn’t Tor Browser specific unless we add exceptions but even then, I don’t see any advantage of this. Persistent malware could implant itself into the Tor Browser files but if it had that level of access, it could also implant itself into ~/.bashrc, etc.
The only place malware can persist is the home directory or shared storage (if enabled as read-write) and it can only ever be executed if W^X is disabled.
