What do you mean? Replace with a different browser? Sounds big. Different forum thread would be useful.
That seems very possible…
At first boot of Whonix, tb-updater copies Tor Browser from /var/cache/tb-binary to user home folder. I.e. it is already “cached”. No download required - it was downloaded to /var/cache/tb-binary during build process. It’s not (anymore) directly stored to user home folder during build process since it’s better to leave home folder creator to the system at first boot for various reasons. On Non-Qubes-Whonix normally /var/cache/tb-binary gets outdated (but that would be easy to change) but in Qubes-Whonix it will be updated on tb-updater upgrades. Details here: https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#Platform-specific_Issues:_Qubes-Whonix_.E2.84.A2
To simplify what I said above.
By running tb-starter / torbrowser (/usr/bin/torbrowser by Whonix developers) it copies - if no such folder already exists yet - from /var/cache/tb-binary to user home folder. And the destination folder is already configureable by environment variables. We might already be in a good position to implement what you suggested. tb-starter probably has already sufficient features to help with whatever is needed.
Would it be sane for sandbox-app-launcher to change environment variable $HOME?
export HOME=/tmp/test
echo ~
/tmp/test
If that works, don’t even need to set tb-starter environment variables. Just set HOME environment variable and run torbrowser? That would copy Tor Browser to correct folder and start it. Briefly tested with export HOME=/tmp/test just now.
In summary: if HOME is correct, just run torbrowser? Would that help to copy Tor Browser into sandbox-app-launcher home folder and execute it from there?
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”.