1

Since I first knew of Docker, I thought it might be the solution for several problems we are usually facing at the lab. I work as a Data Analyst for a small Biology research group. I am using Snakemake for defining the -usually big and quite complex- workflows for our analyses.

From Snakemake, I usually call small scripts in R, Python, or even Command Line Applications such as aligners or annotation tools. In this scenario, it is not uncommon to suffer from dependency hell, hence I was thinking about wrapping some of the tools in Docker containers.

At this moment I am stuck at a point where I do not know if I have chosen technology badly, or if I am not able to properly assimilate all the information about Docker.

The problem is related to the fact that you have to run the Docker tools as root, which is something I would not like to do at all, since the initial idea was to make the dockerized applications available to every researcher willing to use them.

In AskUbuntu, the most voted answer proposes to add the final user to the docker group, but it seems that this is not good for security. In the security articles at Docker, on the other hand, they explain that running the tools as root is good for your security. I have found similar questions at SO, but related to the environment inside the container.

Ok, I have no problem with this, but as every moderate-complexity example I happen to find, it seems it is more oriented towards web-applications development, where the system could initially start the container once and then forget about it.

Things I am considering right now:

  • Configuring the Docker daemon as a TLS-enabled, TCP remote service, and provide the corresponding users with certificates. Would there be any overhead in running the applications? Security issues?
  • Create images that only make available the application to the host by sharing a /usr/local/bin/ volume or similar. Is this secure? How can you create a daemonized container that does not need to execute anything? The only example I have found implies creating an infinite loop.
  • The nucleotid.es page seem to do something similar to what I want, but I have not found any reference to security issues. Maybe they are running all the containers inside a virtual machine, where they do not have to worry about these issues, due to the fact that they do not need to expose the dockerized applications to more people.

Sorry about my verbosity. I just wanted to write down the mental process (possibly flawed, I know, I know) where I am stuck. To sum up:

Is there any possibility to create a dockerized command line application which does not need to be run using sudo, is available for several people in the same server, and which is not intended to run in a daemonized fashion?

Thank you in advance.

Regards.

Community
  • 1
  • 1
Fernandez
  • 259
  • 3
  • 13
  • You say "The problem is related to the fact that you have to run the Docker tools as root," this is wrong, in a Dockerfile, you can use the `USER` in order to use a non-privileged account, see the doc http://docs.docker.com/reference/builder/#user – user2915097 Jun 05 '15 at 09:23
  • Thank you for your comment. Yes, but that refers to inside the container. It changes the user running the processes inside, and that affects the following RUN, CMD and ENTRYPOINT commands. But, in this case, I was talking about the outside, the user who actually runs the docker container form the host. – Fernandez Jun 05 '15 at 10:50

1 Answers1

2

If users will be able to execute docker run then will be able to control host system just because they could map files from host to container and in container they always could be root if they could use docker run or docker exec. So users should not be able to execute docker directly. I think easiest solution here to create scripts which run docker and these scripts could either have suid flag or users could have sudo access to them.

ISanych
  • 21,590
  • 4
  • 32
  • 52
  • Thanks a lot! Actually, the nucleotid.es project page talked about writing scripts acting as wrappers for the call. I do not recall reading anything about the suid flag in that case, but I am going to try it this way. I think I was mentally blocked, and could not see beyond the place I was stuck in. – Fernandez Jun 05 '15 at 10:52
  • I have tried to implement this idea, but I have come over the following [information](http://www.tuxation.com/setuid-on-shell-scripts.html), and that has brought again my security concerns. It seems that what I would like to do might have nothing to do with Docker, I think. – Fernandez Jun 08 '15 at 09:50
  • 1
    Yes, it is not directly related to docker. suid scripts are easier to use, but if they disabled you still could use wrapper or sudo approach. As article is saying some distros disable suid scripts because it is easy to make a mistake in them which will lead to exploit - yes you need to be careful with them - don't allow users to specify docker parameters and/or executing command, validate parameters when you need them. Or you could use another language (c/go/python) for launchers, but you still need to allow only necessary parameters and you still need to validate them. – ISanych Jun 08 '15 at 11:14