I highly doubt the fingerprint would be much different with the hardening enabled, if at all. The sandboxing shouldn’t be visible to websites as it doesn’t affect anything internally. hardened_malloc might change the fingerprint (you can see differences in about:memory) but I doubt websites can detect this.
The warning with the sandboxed-tor-browser project is likely because that sandboxing was part of the actual browser and not some external thing like firejail.
I also think we should be using something like bubblewrap for sandboxing for reduced attack surface but that’s a whole other discussion.
Would be interesting to know why Tor Project deprecated its bubblewrap based sandbox. References and this might help to re-vitalize bubblewrap based sandbox:
I could volunteer for bubblewrap. The only problem is that you need to manually create seccomp filters with actual C code and I don’t know how to do that.
The rest of the sandboxing (namespaces, filesystem stuff, capabilities etc.) is fine and easy to use. It’s just we can’t filter syscalls with seccomp easily.
Can bubblewrap be combined with firejail / apparmor / hardened malloc? Useful?
Or is combination with firejail for example unnecessary and bubblewrap is to be seen as a replacement for firejail?
Keep using firejail for that?
Could you create a pull request / comparison against Tor Browser original please?
Not to get it merged, but to see the diff against last version by Tor Project.
Could you please consider discussing your fork on a mailing list by Tor Project (probably tbb-dev Info Page)?
It would likely just add attack surface and not really be useful. I’ve messed around with running firejail in bubblewrap before and it was hard to actually get it going and it required root.
A combination is unnecessary at best. It would likely degrade security. bubblewrap is meant to be a replacement.
If we do start using bubblewrap, I’d still recommend we keep firejail. It has lots of pre-made profiles we can use. We can configure bubblewrap sandboxes for a few programs ourselves and use firejail for any others. Firejail would also be much easier for a user to use as it can just be done like firejail program but we can create our own scripts so bubblewrap can be used like that.
Yes, they talk about the perfect sandbox and making sure this sandbox does not leak “we are in a sandbox”. But in a world where the main security thread for Tor Browser is to “ping home” and deanon a user, that fingerprint/knowing you use a sandbox is nothing if you can stop hackers from pinging home.
@madaidan@Patrick
Bubblewrap is like Firejail, but implemented in Golang (memory safe). And they use Linux namespaces for isolation + seccomp + capabilities + Apparmor (optional).
Hardened malloc could be used? IDK, it is something apart.
I’m not aware of any way for a website to detect the browser is in a sandbox unless the sandbox is poorly implemented or the website attempts to give you malware.
No, bubblewrap is in C and doesn’t use AppArmor. sandboxed-tor-browser is in golang so that’s probably where you got confused.
The sandboxing wouldn’t affect that. The Tor Browser displays the same set of fonts regardless of the environment it’s in and the sandboxing doesn’t do anything with hardware.