Access to docker.sock

[shufps]

Giving a typescript app access to the system docker.sock is inherently a bad idea.

It gives your app root access to the host.

Please provide a docker-compose.yml setup that doesn't need this.

I would like to try the sv2-ui - but I can't, it's a big no-go.

[GitGab19]

I can see how mounting the docker.sock can be a problem, but the reason behind it was to be able to create, experiment, validate, and consolidate a better UX in an easy way.

More specifically, I'm referring to the possibility of:

• pulling a specific docker image, configure and run it, based on runtime users' inputs
• changing mining mode (e.g. switching from solo mining to pool mining) at runtime --> this requires containers to be restarted
• switching from JD to non-JD mode --> this requires restarting tProxy container and killing JDC's one
• changing some configuration fields at runtime --> this requires restarting the involved containers (JDC or tProxy, or both)
• reading containers logs for better diagnostic to show proper errors on the UI
• avoiding the need for asking to users a Bitcoin IPC socket path before even running anything

To summarize, what we had before the UI is exactly what you are looking for now, a simple docker-compose.yml to be configured manually, without any security implications. And that's what we have in the sv2-apps repository, more specifically here: https://github.com/stratum-mining/sv2-apps/tree/main/docker

If you want to see the UI, without having the ability to do anything I mentioned above from it, you can do the following:

• clone the sv2-apps repo
• configure what's needed (by reading docs there) and run the docker-compose
• clone the sv2-ui repo here
• run the UI only with npm run dev:ui from this repo
• open http://localhost:5173/ on your browser

[GitGab19]

The real sustainable alternative is to have all this orchestration logic inside a single, rust sv2-client, which embeds and uses APIs exposed by the underlying applications (JDC and tProxy) to control them based on users' needs.

At that point we could make all the orchestration logic we currently have here obsolete, removing also the security risks you're complaining about.

But this is a longer-term goal, and before doing that, we need to validate our UX assumptions with users.

You can find more details about the overall plan in the following gdoc: https://docs.google.com/document/d/1hzxH1Fktq-tk9bwBO1GoxJyXKpASsg51IYStK9xXk0c/edit?usp=sharing

[shufps]

Thx for your extensive reply!

To summarize, what we had before the UI is exactly what you are looking for now, a simple docker-compose.yml to be configured manually, without any security implications. And that's what we have in the sv2-apps repository, more specifically here: https://github.com/stratum-mining/sv2-apps/tree/main/docker

Interesting, thank you very much, I'll try that 🙌

I understand now why you chose the approach you did, but I still feel uneasy about it.

I’m not saying that the current implementation is insecure as it stands. However, we have seen multiple incidents in the past where NPM dependencies were compromised, sometimes in very subtle ways. In that scenario, having access to docker.sock available to the application — and therefore potentially to a compromised dependency — feels like one of the worst possible failure modes.

One of the main reasons to run something inside a Docker container is to create a security boundary: the application is isolated from the host, has a limited view of the system, and should only get the permissions it actually needs. But once the Docker socket is mounted into that container, this security model is largely undermined. Code inside the container can potentially control Docker on the host, start new containers, mount host paths, or otherwise escape the intended isolation.

So the issue is not only whether the current code is safe today. The bigger concern is that the blast radius becomes extremely large if anything in the dependency chain is ever compromised. Access to the Docker socket is effectively a very powerful host-level capability, and exposing it to code that also relies on a large third-party dependency tree feels risky.

That is why it has such a bad taste to me. We use containers partly to reduce risk and contain damage, but by exposing docker.sock directly, we risk bypassing exactly the security boundary we are relying on.

But I guess I’m not telling you anything new here.

It's just a general high risk I wanted to point out.

But thx, I'll try the other approach - when it's working it's good enough.

Feel free to close this issue if you like.

[GitGab19]

I definitely see your point, and it's valuable, thanks for sharing it.

As I said above, the current tradeoff is still valuable for the purpose of creating and validating a good UX in the first phase of this project.

But we should probably make the security implications clear somewhere in the README, I'll think about it.

[GitGab19]

A better approach, which would mitigate the majority of concerns expressed in this issue, is to leverage the DockerInDocker image, and have it as a service in a docker-compose.yml with our sv2-ui.

As stated in this comment, we might need to do that for Umbrel deployment in the near future.

I'll make sure to take this into consideration while working on #131.