-
Notifications
You must be signed in to change notification settings - Fork 18.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'docker' group is root equivalent and bypasses policy, audit #9976
Comments
The docker client and/or its users should use the usual mechanisms for escalating privileges to root, such as sudo. Alternatively Docker should check with a system such as polkit to respect system policy and act on behalf of the client based on that. |
This is not a bug. Access to the Docker API is effectively root access. Even lacking --privileged, there are numerous mechanisms to avoid system policy if one has access to the docker socket or API. Docker itself, of course, needs better auth (N & Z) and audit mechanisms. PRs such as #8265 seek to begin addressing these issues. If there is a need for greater documentation, then we should pursue that. |
See https://docs.docker.com/articles/security/ and the Docker Daemon Attack Surface section. It covers this extensively. |
As @phemmer said, this is explicitly outlined in the documentation around security. sudo does work, just don't add untrusted users to the docker group ( don't add a docker group at all ). |
Yes, it's unfortunate that many distros create this group by default, and in the end users are encouraged to use it. Where it really should only used in special situations. |
This needs more prominent documentation. Yes it's there, half way down the page, but it's effectively hidden in a "security speak" document. Most casual readers will see the first paragraph, and read it as "I see they thought of security -- they're running things in the own name spaces, containers are isolated" and stop there. And not read the huge gaping hole -- anyone with privileges to That belongs in the first paragraph as a strong warning. That may not sound as good to the readers -- but they need to know that granting membership to the docker group is essentially the same as sudo. I could make a case that the default uid/gid for |
@markriggins would you be interested in contributing, and opening a pull-request with the changes you think would improve that page? The Markdown file that is used to generate that page can be found in this repository; https://github.com/docker/docker/blob/master/docs/articles/security.md If this is the first time you're contributing to docker, you may find the contributing guide useful; it contains information on how to set up your dev environment, testing the docs, and creating a pull-request. If you need help at any point with contributing, feel free to ask for assistance in the #docker-dev IRC channel. |
Yes -- very taxed for time at the moment - but managed to write an update. On Tue, Oct 27, 2015 at 6:04 AM, Sebastiaan van Stijn <
|
Correct, no changes are ever made to this repository directly, everything is done via pull-requests. You should be able to create a pull-request from that; but don't forget to sign-off and amend your commit, otherwise it will not pass validation here. https://docs.docker.com/project/work-issue/ |
I'll try -- very busy right now On Tue, Oct 27, 2015 at 10:09 AM, Sebastiaan van Stijn <
|
Configure the mode to use sudo when running docker commands as I don't want my regular user to be part of the docker group (mainly for security reasons see [1]). [1]: moby/moby#9976
- Restart on crash - Wallet and account setup via CLI (because you need that anyway for the seed) - RPC sample - Updating - Bash alias via container name - Formatting
Due to the
--privileged
in docker, anyone added to the 'docker' group is root equivalent. Anyone in the docker group has a back door around all privilege escalation policy and auditing on the system.This is different from someone being able to run running sudo to root, where they have policy, and audit applied to them.
The text was updated successfully, but these errors were encountered: