What user does the Hass.io container run under?

Installation Home Assistant OS
1

Hopefully the title says it all. I’m pretty new to Home Assistant and docker in general. I haven’t found a good way to determine this.

2

should be root.

3

Hmm… if it’s truly root, isn’t that concerning? I realize Hass.io makes a ton of things simpler. But even the Home Assistant website recommends using the principle of least privilege.

4

It doesn’t really matter with hass.io and docker in general, since all addons and homeassistant are running in their own isolated container. The only thing the homeassistant container can access is the configuration, which also applies to a regular venv installation. In fact, containers are safer than regular installations since if something goes wrong it should only affect a single container. Containers run under root so that they can access directories that were specifically bind-mounted to them (usually just configuration files etc.).

5

You’re only root within the container.

It’s like being the king of your living room, as opposed to the king of the country.

6

But you can still access kernel services right?

If I understand this correctly it has access to:

  • /var/run/docker.sock
  • /var/run/hassio-hc.sock
  • /var/run/dbus ← the entire directory
  • /usr/share/hassio

Again, i’m no expert in a lot of these topics, so i’m bouncing these ideas off yall to see what you think. I do know that security is certainly a 90/10 rule and rarely is it good to run something with privileged access. Given home assistant appears to have a plugin framework, it seems the root access allows more potential for it to be abused even if it’s in a container.

Even the docker docs caution against running containers as root.

This means that in most cases, containers do not need “real” root privileges at all. And therefore, containers can run with a reduced capability set; meaning that “root” within a container has much less privileges than the real “root”. For instance, it is possible to:
-deny all “mount” operations;
-deny access to raw sockets (to prevent packet spoofing);
-deny access to some filesystem operations, like creating new device nodes, changing the owner of files, or altering attributes (including the immutable flag);
-deny module loading;
-and many others.
This means that even if an intruder manages to escalate to root within a container, it is much harder to do serious damage, or to escalate to the host.
This doesn’t affect regular web apps, but reduces the vectors of attack by malicious users considerably.

One primary risk with running Docker containers is that the default set of capabilities and mounts given to a container may provide incomplete isolation, either independently, or when used in combination with kernel vulnerabilities.
Docker supports the addition and removal of capabilities, allowing use of a non-default profile. This may make Docker more secure through capability removal, or less secure through the addition of capabilities. The best practice for users would be to remove all capabilities except those explicitly required for their processes.

Here are 3 more articles that also agree:

Here is something I’m toying with as a solution:

1 Like