container user should not be root and should not have sudo installed

[stonemelody]

Linux security best practices say one should not run as root but instead use sudo if needed. This rule applies to applications in containers as well. Ideally, a container that is used just to run chia farmer/harvester/wallet should not even have sudo installed as all prerequisites to run chia should already be in the container image

[Starttoaster]

In my opinion, if the user running in the container were to change from root, there would need to still be a way to continue running as root. In this case, security comes at the expense of usability, depending on what you want to do. Somebody might hop in the container, want to install tree, etc.

What's your thoughts on that? Did you want to take a stab at this?

[stonemelody]

I think maybe we have different ideas of what this container is supposed to accomplish

If the container is meant to be as a dev container, then sure running as root is fine. What I've seen from a lot of people is that this is the container that they run their chia client with (on a NAS or just to make life easy on their local machine). In the latter case users just launch the container, making sure that they set the env vars such that it will do what they want. In that case, there's no reason to run as root/have sudo on the container at all

Having a container not running as root by default doesn't preclude a user from asking docker to make their user root on the command line if they know what they're doing (docker exec -u root <running container name> or docker run -u root ghcr.io/chia-network/chia)

If there's absolutely a need to run the container as root by default, then it seems like it would be good to have separate tags/container images so that at least users know what they're getting and what they're not

[Starttoaster]

I think maybe we have different ideas of what this container is supposed to accomplish

I think we're actually on the same page. At least a similar one.

What I've seen from a lot of people is that this is the container that they run their chia client with (on a NAS or just to make life easy on their local machine).

The thing about maintaining software, is that there's a lot of different vocal minorities that don't fit into the mold of what you'd argue the majority does. And we have to think about those people too. For example, some people may (and more than likely do) maintain their own images that start with FROM ghcr.io/chia-network/chia:latest and then install a bunch of extra stuff on top and then they actually utilize that resulting image for whatever reason. This would be a breaking change for them, and they'll be (understandably) upset when they realize their existing pipeline was broken upstream.

For what it's worth... I've actually brought up this exact Issue internally on a couple of occasions. I reckon if you were to search through other Issues or the chia-docker channel on the public keybase community, you'll see me bringing up this exact same concern. I think that solving for this concern is likely more complicated than either of us initially thought but I'm happy to hear your ideas for how to solve it in a sane way. I think separate tags may be the best way, and I think I'm leaning towards keeping :latest the way it is for now, for reasons I've already said above.

Personally, looking into commonly mentioned exploits for escaping containers, it usually requires privileged containers (not really relevant here) or access to the host to bind mount host directories owned by root into the container, in which case you already have a bad actor on your host and that whole system is hosed anyway. Happy to be proven wrong there, though.

Either way, I'd be happy to review a PR that accomplishes this!

[Starttoaster]

Also, if there were a non-root variant of this image, it would be cool if it followed the common linuxserver.io pattern of allowing you to specify a UID and GID via environment variables.

[stonemelody]

Also, if there were a non-root variant of this image, it would be cool if it followed the common linuxserver.io pattern of allowing you to specify a UID and GID via environment variables.

linuxserver.io uses the s6-overlay project and relies on its setuid magic or something (it's unclear from a moderate amount of digging what they actually do to accomplish running not as root). Unless you want to take a dependency on s6-overlay and start maintaining different dockerfiles for different architectures (s6-overlay has different arch packages) or explicitly support on x86_64 or other architectures that may not be the best course of action.

If a container is running as a stateless container (i.e. harvester), then not being able to set a particular user/group ID isn't such a big deal. If the directory that the plots are in has read permissions then it will be fine. The only tricky part would be if the user did a mount for the database files as that would require write permissions. Again, not super complicated to solve if users can set write permissions on the host directory, though admittedly not the most elegant solution

[wallentx]

It seems you'd have to work around this issue
Chia-Network/chia-blockchain#11257

[stonemelody]

I've been playing around a little bit trying to get an s6-overlay image working to see what it would be like, but there's an issue with the way s6-overlay drops permissions and how python's os.path.expanduser() functions. s6-overlay can properly drop permissions for the program, but expanduser() still returns root, causing chia to fail with a permission error as it tries to access root's homedir. This is specifically happening for the keyring so it could be worked around with env vars, but that seems like a somewhat brittle solution

[Starttoaster]

I suppose being able to pass the host user's UID/GID is a bit of scope creep though it would have been nice to have :)

Have you gotten any non-root version of chia-docker to run (eg. without s6-overlay)?

[stonemelody]

yea, sorry for the delay. Work has been busy lately so I've been a tad behind on stuff. I'm not sure how you want to setup the tagging of images and stuff, but I'll make a PR and we can discuss it there

[github-actions]

'This issue has been flagged as stale as there has been no activity on it in 14 days. If this issue is still affecting you and in need of review, please update it to keep it open.'

[github-actions]

'This issue was automatically closed because it has been flagged as stale and subsequently passed 7 days with no further activity.'

[meebey]

I am deploying the official docker image (ghcr.io/chia-network/chia:main 3c496d8fd5aa) on a server and noticed that it runs the Chia daemon as the root user:

root@8cfb92fd990f:~# ps auxf
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         284  0.0  0.0   4608  3632 pts/0    Ss   06:10   0:00 /bin/bash
root         471  0.0  0.0   8480  4244 pts/0    R+   06:11   0:00  \_ ps auxf
root           1  0.0  0.0   4344  3228 ?        Ss   05:59   0:00 bash /usr/local/bin/docker-start.sh
root          78  0.2  0.3 411924 75648 ?        Sl   05:59   0:01 chia_daemon
root          88  0.3  0.4 382316 87916 ?        Sl   05:59   0:02  \_ chia_harvester
root          89  0.3  0.4 308556 86916 ?        Sl   05:59   0:02  \_ chia_farmer
root          90 12.6  2.8 1358104 570032 ?      Sl   05:59   1:33  \_ chia_full_node
root         159 61.0  2.4 1301400 484452 ?      R    06:00   6:34  |   \_ chia_full_node_block_validation_worker
root         160 61.1  2.4 1301400 484452 ?      R    06:00   6:34  |   \_ chia_full_node_block_validation_worker
root         161 63.7  2.4 1301400 484452 ?      R    06:00   6:51  |   \_ chia_full_node_block_validation_worker
root         162 62.6  2.4 1301400 484452 ?      R    06:00   6:44  |   \_ chia_full_node_block_validation_worker
root          91  2.3  1.1 770556 234112 ?       Sl   05:59   0:17  \_ chia_wallet
root         135  3.9  0.8 623060 169408 ?       S    05:59   0:28      \_ chia_wallet_worker
root         136  2.9  0.7 621012 158684 ?       S    05:59   0:21      \_ chia_wallet_worker
root         137  2.9  0.7 621012 158636 ?       S    05:59   0:21      \_ chia_wallet_worker
root         138  2.9  0.7 621012 158632 ?       S    05:59   0:21      \_ chia_wallet_worker
root          93  0.0  0.0   2936   916 ?        S    05:59   0:00 tail -F /root/.chia/mainnet/log/debug.log
root          94  0.0  0.0   2936   900 ?        S    05:59   0:00 tail -F /dev/null
root@8cfb92fd990f:~# 

So this issue isn't stale but still present and should be re-opened.

As far as I can tell no functionality in the chia node software seems to need super-user privileges of root (no privileged network ports, nothing changes system-owned files). My previous node ran fine without root. From a security point-of-view, running any process as root, even when running inside a container puts the system security of the host and other containers running on the same host at risk in case of a container escape vulnerability. Such escape vulnerability happened just a month ago. So switching to an unprivileged user would greatly improve the host system and container security.

[Starttoaster]

As far as I can tell no functionality in the chia node software seems to need super-user privileges of root

This is a very flexible image and runs many of the services bundled in a typical chia installation. Including seeders (runs on port 53.) But the use of super user privileges also extends over to installing dependencies for timelord processes, as well as plotters. People who run their farms in chia-docker today likely have their CHIA_ROOT and plot directories owned by root, and switching to a non-root user would break their farms just by updating, and potentially on accident if they use the :latest tag. A lot of functionality that people utilize in this image does actually require super user privileges.

An iteration of this container that doesn't use root privileges may be nice to have, I agree, but would indeed be a breaking change to many consumers of the image.

The vulnerability linked above for container escaping matches some of the unique requirements for exploitation as the other ones I've seen. Often requiring access to the host running the container already. In the case of this one, the vulnerability needs to be purposefully built into the image at build time, alternatively the exploit only sounds to be possible if the user of the image built it on the same machine they're running it on, on a machine that has runc version <=1.1.11 installed, if I'm reading the vulnerability summary right. That one is a bit worse than the other cases I've seen, simply due to appearing to not need initial access to the host computer.