Controlling Docker from an unprivileged user is a huge security hole, how to counteract?
up vote
-1
down vote
favorite
Consider a web application developer who works through an unprivileged user account without any sudo permissions. Since the developer's tools do not require any root access, that is the most secure development environment possible (the kind of development environment I prefer). If one works with thousands of unfamiliar libraries and uses web browsers in their development environment, I consider that a sensible and recommendable precaution.
Usually the developer enters their password only to unlock their machine, but never on the command line. Work is comfortable that way. To keep that comfortability, after they decide to install Docker, the developer adds their unprivileged user to the docker group, which secretly turns their unprivileged account into an account with superuser powers: A Docker container mounting system directories may do everything, even change files owned by root, which is a huge security hole.
To plug that hole, one could remove the unprivileged user from the docker group and instead add NOPASSWD entries to the sudoers file for the most important but still harmless docker commands, such as docker start some-container or docker ps.
Example: sudo docker ps
If the execution of an allowed Docker command may lead to container builds (such as docker build or docker-compose up), input files need to be read-only for the unprivileged user and owned by root or some other "secure" user, so that no rogue may manipulate them. Taking care of that is a bit cumbersome.
Apart from that, two questions come into my mind:
- Is that secure enough or is the developer still failing to see something dangerous introduced by starting to work with Docker?
- Is that the only secure way of providing control over Docker without having to type the password when using
sudoto control Docker?
security sudo docker sudoers
asked Nov 23 at 21:36
user1625837
3718
add a comment |
up vote
-1
down vote
favorite
Consider a web application developer who works through an unprivileged user account without any sudo permissions. Since the developer's tools do not require any root access, that is the most secure development environment possible (the kind of development environment I prefer). If one works with thousands of unfamiliar libraries and uses web browsers in their development environment, I consider that a sensible and recommendable precaution.
Usually the developer enters their password only to unlock their machine, but never on the command line. Work is comfortable that way. To keep that comfortability, after they decide to install Docker, the developer adds their unprivileged user to the docker group, which secretly turns their unprivileged account into an account with superuser powers: A Docker container mounting system directories may do everything, even change files owned by root, which is a huge security hole.
To plug that hole, one could remove the unprivileged user from the docker group and instead add NOPASSWD entries to the sudoers file for the most important but still harmless docker commands, such as docker start some-container or docker ps.
Example: sudo docker ps
If the execution of an allowed Docker command may lead to container builds (such as docker build or docker-compose up), input files need to be read-only for the unprivileged user and owned by root or some other "secure" user, so that no rogue may manipulate them. Taking care of that is a bit cumbersome.
Apart from that, two questions come into my mind:
- Is that secure enough or is the developer still failing to see something dangerous introduced by starting to work with Docker?
- Is that the only secure way of providing control over Docker without having to type the password when using
sudoto control Docker?
security sudo docker sudoers
asked Nov 23 at 21:36
user1625837
3718
Not too familiar with these issues (and yes, I'm aware thatdockergroup membership grants access equivalent toroot), but see docs.docker.com/engine/security/security
– bwDraco
Nov 23 at 21:57
Of course I read that document. But it does not provide a solution to my problem. At least as far as I understand the content of the document.
– user1625837
Nov 24 at 19:43
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
Consider a web application developer who works through an unprivileged user account without any sudo permissions. Since the developer's tools do not require any root access, that is the most secure development environment possible (the kind of development environment I prefer). If one works with thousands of unfamiliar libraries and uses web browsers in their development environment, I consider that a sensible and recommendable precaution.
Usually the developer enters their password only to unlock their machine, but never on the command line. Work is comfortable that way. To keep that comfortability, after they decide to install Docker, the developer adds their unprivileged user to the docker group, which secretly turns their unprivileged account into an account with superuser powers: A Docker container mounting system directories may do everything, even change files owned by root, which is a huge security hole.
To plug that hole, one could remove the unprivileged user from the docker group and instead add NOPASSWD entries to the sudoers file for the most important but still harmless docker commands, such as docker start some-container or docker ps.
Example: sudo docker ps
If the execution of an allowed Docker command may lead to container builds (such as docker build or docker-compose up), input files need to be read-only for the unprivileged user and owned by root or some other "secure" user, so that no rogue may manipulate them. Taking care of that is a bit cumbersome.
Apart from that, two questions come into my mind:
- Is that secure enough or is the developer still failing to see something dangerous introduced by starting to work with Docker?
- Is that the only secure way of providing control over Docker without having to type the password when using
sudoto control Docker?
security sudo docker sudoers
asked Nov 23 at 21:36
user1625837
3718
Consider a web application developer who works through an unprivileged user account without any sudo permissions. Since the developer's tools do not require any root access, that is the most secure development environment possible (the kind of development environment I prefer). If one works with thousands of unfamiliar libraries and uses web browsers in their development environment, I consider that a sensible and recommendable precaution.
Usually the developer enters their password only to unlock their machine, but never on the command line. Work is comfortable that way. To keep that comfortability, after they decide to install Docker, the developer adds their unprivileged user to the docker group, which secretly turns their unprivileged account into an account with superuser powers: A Docker container mounting system directories may do everything, even change files owned by root, which is a huge security hole.
To plug that hole, one could remove the unprivileged user from the docker group and instead add NOPASSWD entries to the sudoers file for the most important but still harmless docker commands, such as docker start some-container or docker ps.
Example: sudo docker ps
If the execution of an allowed Docker command may lead to container builds (such as docker build or docker-compose up), input files need to be read-only for the unprivileged user and owned by root or some other "secure" user, so that no rogue may manipulate them. Taking care of that is a bit cumbersome.
Apart from that, two questions come into my mind:
- Is that secure enough or is the developer still failing to see something dangerous introduced by starting to work with Docker?
- Is that the only secure way of providing control over Docker without having to type the password when using
sudoto control Docker?
security sudo docker sudoers
security sudo docker sudoers
asked Nov 23 at 21:36
user1625837
3718
asked Nov 23 at 21:36
user1625837
3718
edited Nov 23 at 21:53
asked Nov 23 at 21:36
user1625837
3718
asked Nov 23 at 21:36
user1625837
3718
asked Nov 23 at 21:36
user1625837
3718
3718
Not too familiar with these issues (and yes, I'm aware thatdockergroup membership grants access equivalent toroot), but see docs.docker.com/engine/security/security
– bwDraco
Nov 23 at 21:57
Of course I read that document. But it does not provide a solution to my problem. At least as far as I understand the content of the document.
– user1625837
Nov 24 at 19:43
add a comment |
Not too familiar with these issues (and yes, I'm aware thatdockergroup membership grants access equivalent toroot), but see docs.docker.com/engine/security/security
– bwDraco
Nov 23 at 21:57
Of course I read that document. But it does not provide a solution to my problem. At least as far as I understand the content of the document.
– user1625837
Nov 24 at 19:43
Not too familiar with these issues (and yes, I'm aware that
docker group membership grants access equivalent to root), but see docs.docker.com/engine/security/security– bwDraco
Nov 23 at 21:57
Not too familiar with these issues (and yes, I'm aware that
docker group membership grants access equivalent to root), but see docs.docker.com/engine/security/security– bwDraco
Nov 23 at 21:57
Of course I read that document. But it does not provide a solution to my problem. At least as far as I understand the content of the document.
– user1625837
Nov 24 at 19:43
Of course I read that document. But it does not provide a solution to my problem. At least as far as I understand the content of the document.
– user1625837
Nov 24 at 19:43
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377891%2fcontrolling-docker-from-an-unprivileged-user-is-a-huge-security-hole-how-to-cou%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Not too familiar with these issues (and yes, I'm aware that
dockergroup membership grants access equivalent toroot), but see docs.docker.com/engine/security/security– bwDraco
Nov 23 at 21:57
Of course I read that document. But it does not provide a solution to my problem. At least as far as I understand the content of the document.
– user1625837
Nov 24 at 19:43