chaperone-docker
chaperone-docker copied to clipboard
garywiz
run chaplocal without being in docker group
As things stand, the chaplocal script doesn't work as intended unless run by a non-root user who is also a member of the docker group. Could we have the chaplocal script recognise when it can't access the docker socket, and call docker via sudo in those circumstances?
Having a user be a member of the docker group is convenient, and sometimes appropriate, but it's equivalent in power to having password-less sudo access, which is to say it's a security risk. In most docker uses users can decide for themselves whether to take that risk, or use sudo, which may ask for a password. I'd like to have chaplocal respect that decision and do the right thing when group based access to the docker socket is not available.
Currently, If chaplocal is run as a non-root user without docker group access, then it will fail to run docker. If chaplocal is run using sudo, then it will create the application directory as owned by root, both inside and outside the container. root access will then continue to be needed to work on and run the container, and the intended permissions limits for the app in the container limits don't get applied.
There probably wants to be a check for presence of sudo also. It's very widespread, but not universal.
If I pipe the output of the get-chaplocal task to a file, and edit it to have sudo in front of the two docker commands, before running it through the shell, that seems to get me through the first bit OK. The sudo commands get replicated to the chaplocal script in my local directory.
When I run chaplocal, I get a directory where more similar edits are needed to run.sh and build.sh, and perhaps bin/chaplocal, though I suspect that last one may not get used at this stage?
This simple approach doesn't do any checking to see if sudo is actually necessary or appropriate.
Hmm. Docker security.... A few things. First, having chaplocal give a better error message if the user doesn't have permission to run docker is a good idea, regardless.
However, doesn't giving a user "sudo" access to docker create exactly the same vulnerability as making them a member of the 'docker' group? Is it really worth adding sudo complexities to all the scripts (which is surely possible), when the result is the same?
For example, let's take the ultimate security hole:
sudo docker run -it --privileged -v /:/hostroot ubuntu /bin/bash
Any user who has 'sudo' access to docker can do the above, and have the entire root file system available along with most system privileges. Isn't that basically the same as making them a member of the 'docker' group? Even if you configure 'sudo' to support only docker run, once they have a privileged container they can run the docker command from within the privileged container anyway and have total control of the host.
I am really interested in improving security and versatility, I just want to first be sure I understand the reason why 'sudo' support is going to be an improvement.
The significant difference is that sudo may require a password, depending how it is configured.
OK, yep... the password thing. I'll have to debate this over a beer at the pub with a few friends. :-) But, I'll do some experiments to see how pervasive the changes are and see if it creates any dead ends in the deeper scripts. If I can do it easily, I will. Keep this open and I'll keep you posted.
@mc0e I have a new build which, I believe, should work completely using sudo and preserve all functionality. I've tested it, but before I publish it, would it be possible for you to try it to see if you have any comments or suggestions? I want to be sure your use-case is functioning for you.
Which actual image are you using? (chaperone-lamp, etc.) I'll push a temporary test copy and you can give it a go.
@mc0e you will find a complete set of test images at https://hub.docker.com/u/chaptest/
All of these should work using sudo. Please let me know if they work as you expected, and if so, I'll move these into production.
My use case only really involves chaptest/chaperone-baseimage , but that looks to be working fine.
Thanks for testing it. I will put the new images into production soon. I have a few other tests I want to run on CentOS. Expect a release within 2 days.