Hacker News Reader

Comment by hanniabu | Hacker News Reader

> If you are not using Tor Browser and want to fix the security hole without disabling WebSocket completely, running the web browser in a separate network namespace is a workaround - you get a loopback interface which is independent from the main namespace, and you create a NAT interface within the network namespace to allow outgoing traffic. It's also a possibility for a website to probe other machines, such as the setting page on your router. For better protection, you should block all the local addresses defined by RFC1918 via netfilter/iptables as well.

As someone less tech savvy but still concerned, are there any guides available on how to do this?

View on HN

You can look into tools like firejail to make this easier.

+1 for firejail [1]. There's a guide on how to do this for firefox [2] (see the network setup section), but this can be used with other applications as well.

[1] https://firejail.wordpress.com/

[2] https://firejail.wordpress.com/documentation-2/firefox-guide...

Note that the further I went down the sandboxing rabbit-hole, the more questions it raised about whether it's more or actually less secure. The main problem is that in order to work, these tools often use a setuid binary, which actually has more permissions than most users. So in theory if a sandboxed app finds an exploit in the sandboxing program (like firejail) that you're running inside, you could actually be worse off than it breaking out of whatever program you're sandboxing in the first place.

I think in this case though where you're more concerned about the very real problem of websites accessing localhost, it probably outweighs the maybe of a firejail exploit.

> these tools often use a setuid binary, which actually has more permissions than most users.

These tools often drop privileges as soon as the program is executed, in firejail, there's also an option to disalble root entirely within a namespace.

Interesting point, I hadn't made it that far down the rabbit hole. I agree that it's not a complete solution, and possible risks of exploiting the sandbox itself should be taken into account on a case-by-case basis.

It's also possible to run a web browser in a docker container which can be interacted with on the host OS. This avoids the permissions issues with solutions like firejail:

https://blog.jessfraz.com/post/docker-containers-on-the-desk...

`docker` implies access to the Docker daemon, which is not an improvement over the setuid binaries anderspitman found distasteful.

https://docs.docker.com/engine/security/security/#docker-dae...

Genuine question, would LXD be any better? I'm not an expert in containerization but I find it really interesting.

There are some blogs that talk about how to do this: https://blog.simos.info/how-to-easily-run-graphics-accelerat...

If it runs in the same Xwindows session no.

If your docker is in fact podman your rootless might be attainable.

Please don't suggest using Docker to sandbox a GUI app.

That's not a good idea. The attack surface of docker is enormous compared to firejail.

Reply on news.ycombinator.com