4 ms·

So I was going to be snarky about the author not having their linux user as a member of the "docker" group (thus requiring sudo every command) but that sparked

So I was going to be snarky about the author not having their linux user as a member of the "docker" group (thus requiring sudo every command) but that sparked a line of thought; so I'll ask: Is it better practice to leave yourself out of the docker group, thus forcing explicit use of sudo, since the daemon runs as root? Is there a better daemon auth model that's not in use so you can at least have longer-lived tokens, etc? Also, in case you do want to skip the sudo every time (careful with the potential security risk): sudo usermod -aG docker $(whoami)

deleted 10y ago
[deleted]
atmosx 10y ago
Only a developer could ask such a question!!!! I'm joking :-P From a sysadmin standpoint sudo is the right choice. Sudo is an established, well defined, (mostly) bug-free program, designed to specifically for that task. It's tool for the job. You can create specific policies[1] keep track of who, what, when, allow this and deny that. I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. [1] http://linux.die.net/man/5/sudoers http://linux.die.net/man/5/sudoers
- cyphar 10y ago
  > I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. sudo is still better in that case, because sudo leaves an audit trail in your system log. Docker doesn't keep a detailed audit log for every request made by a user.
  - alrs 10y ago
    https://github.com/a2o/snoopy https://github.com/a2o/snoopy
manacit 10y ago
Handing an unprivileged user access to Docker is, functionally, the same as handing them access to sudo. Once you are allowed to run arbitrary Docker containers, you have limitless access to root on the running host. For this reason, I would vastly prefer requiring sudo to communicate with a local Docker daemon. Sudo was designed for this purpose, has the proper logging and fin(er) grained access control.
- lojack 10y ago
  Everyone always says this, and I know security isn't a #1 priority and that it'd be a big mistake to assume Docker is secure -- but, are there any known security issues with Docker that could give sudo access to the host machine? Anything beyond the standard: "Don't trust it because its almost certainly not secure."
  - Titanous 10y ago
    Yes, you can run a privileged container that bind-mounts / on the host into the container. root.
    - emmelaich 10y ago
      I presume that the default selinux policy in redhat7 would stop this. But that would mean using the docker version in redhat7, which tends to trail behind a little.
  - manacit 10y ago
    The issue, as another poster pointed out, is not that there are vulnerabilities in the Docker daemon, but that access to the socket inherently gives you access to run arbitrary containers in privileged mode. This allows you access to the full host: https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities https://docs.docker.com/engine/reference/run/#/runtime-privi... and everything that a normal root user can do. At present, there is no great way to mitigate this if you're tracking the official Docker releases (at least, as far as I know).
cyphar 10y ago
> Is there a better daemon auth model that's not in use so you can at least have longer-lived tokens, etc? Docker does have authorization plugins[1], and there is work to get authentication working[2]. So the answer is "eventually being in the docker group will be safer", but not yet. Personally, I think the future of containers (at least for a lot of the cases I deal with) is going to be with rootless containers[3]. But that's another story. [1]: https://github.com/docker/docker/pull/15365 https://github.com/docker/docker/pull/15365 [2]: https://github.com/docker/docker/issues/14674 https://github.com/docker/docker/issues/14674 [3]: https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774

deleted 10y ago

[deleted]

atmosx 10y ago

Only a developer could ask such a question!!!! I'm joking :-P From a sysadmin standpoint sudo is the right choice. Sudo is an established, well defined, (mostly) bug-free program, designed to specifically for that task. It's tool for the job. You can create specific policies[1] keep track of who, what, when, allow this and deny that. I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. [1] http://linux.die.net/man/5/sudoers http://linux.die.net/man/5/sudoers

cyphar 10y ago
> I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. sudo is still better in that case, because sudo leaves an audit trail in your system log. Docker doesn't keep a detailed audit log for every request made by a user.
- alrs 10y ago
  https://github.com/a2o/snoopy https://github.com/a2o/snoopy

manacit 10y ago

Handing an unprivileged user access to Docker is, functionally, the same as handing them access to sudo. Once you are allowed to run arbitrary Docker containers, you have limitless access to root on the running host. For this reason, I would vastly prefer requiring sudo to communicate with a local Docker daemon. Sudo was designed for this purpose, has the proper logging and fin(er) grained access control.

lojack 10y ago
Everyone always says this, and I know security isn't a #1 priority and that it'd be a big mistake to assume Docker is secure -- but, are there any known security issues with Docker that could give sudo access to the host machine? Anything beyond the standard: "Don't trust it because its almost certainly not secure."
- Titanous 10y ago
  Yes, you can run a privileged container that bind-mounts / on the host into the container. root.
  - emmelaich 10y ago
    I presume that the default selinux policy in redhat7 would stop this. But that would mean using the docker version in redhat7, which tends to trail behind a little.
- manacit 10y ago
  The issue, as another poster pointed out, is not that there are vulnerabilities in the Docker daemon, but that access to the socket inherently gives you access to run arbitrary containers in privileged mode. This allows you access to the full host: https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities https://docs.docker.com/engine/reference/run/#/runtime-privi... and everything that a normal root user can do. At present, there is no great way to mitigate this if you're tracking the official Docker releases (at least, as far as I know).

cyphar 10y ago

> Is there a better daemon auth model that's not in use so you can at least have longer-lived tokens, etc? Docker does have authorization plugins[1], and there is work to get authentication working[2]. So the answer is "eventually being in the docker group will be safer", but not yet. Personally, I think the future of containers (at least for a lot of the cases I deal with) is going to be with rootless containers[3]. But that's another story. [1]: https://github.com/docker/docker/pull/15365 https://github.com/docker/docker/pull/15365 [2]: https://github.com/docker/docker/issues/14674 https://github.com/docker/docker/issues/14674 [3]: https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774