Proposal: option to disable docker exec

[inthecloud247]

Adding the ability to disable the docker exec command will help enhance security and encourage best practices for companies running docker on production systems.

[cngkaygusuz]

Improving on the idea, there should be a set of commands that is allowed to execute within a given container, everything else is no-go. Gives the best of the both worlds but doesn't sound simple.

[cpuguy83]

If someone has access to Docker, they have access to your entire system, can join namepsaces, etc.
Disabling docker exec would not enhance security at all.

[gdm85]

Agree with @cpuguy83, at very least you are allowing docker run thus I don't see what exec gives more or less

[jessfraz]

Closing

[inthecloud247]

Specifically with docker exec, the issue is that there may be things that were started in the container via the docker exec command after the container was started. And there isn't any way to really inspect or know what was exec'd in a running container. Leading to instant devops hairball scenarios where production does funny stuff and nobody knows why...

docker run commands are a bit different. You can inspect the container to see what run command was used to start a container. And yes there are ways to tamper with running containers without using docker exec, but by locking down docker exec, the attack surface area as well as the potential for mis-use is mitigated.

Additionally, from a philosophical standpoint, the docker exec command breaks the simple 'docker as self-contained deployable artifact' encapsulation model in a way that people running large distributed systems may want to disable. ( A bit unrelated, but for similar reasons there are scenarios where it would be useful to disable the ability to bind-mount volumes into containers....)

To be clear tho, I do think that docker exec is a useful command, particularly for debugging. I'm already starting to use it as a replacement for some openssh/dropbear/nsenter-based solutions.

[gdm85]

@inthecloud247 I think you could hijack API calls and deny those for exec, if that's your use-case. You could do this with a shim/wrapper over the docker API (or check how people are already doing this), and generally you should already have this in place if you are trying to alllow a subset of Docker commands for your users.

Unrelated, but in #8703 I was discussing with @LK4D4 if this is going to become synchronous and returning the process exit code. I also see it as a tool for debugging/deployment, but no matter what people can/will do with it, I think it is useful as far as it is kept a generic command.
I do not think it breaks the encapsulation model because Docker was never meant to be provided to untrusted users from your Docker host :)

[inthecloud247]

@cpuguy83 @gdm85 The ability to filter API calls for different users should probably be included in base docker functionality. I haven't seen any public discussion of docker's 'enterprise' roadmap, but I hope there won't be an 'enterprise' docker version that supports ldap/pam or multiple user management.

@gdm85 Agreed that we can definitely implement a shim/wrapper with devops glue. DevOps engineers twiddle their thumbs all day anyhow and could use some real work now and again. :D But seriously, expecting users to implement shims or wrappers to enhance security leads to situations where most users will simply be unprotected. If I'm helping a company secure their infrastructure in preparation for a PCI/ISO or security audit, I would either disable docker exec or only enable it for specific 'superuser' docker users.

At least the new Docker 1.3 seems to now encourage secure api endpoint connections. But then allowing docker exec calls over that connection seems to be the security equivalent of passing passwords in cleartext because the links are encrypted.

I'd be interested to contribute towards this effort if it's something that would be of interest to incorporate into docker core, but if not I'll try and use a non docker-specific workaround that I can use for other api-trusting-by-default systems like elasticsearch. The goal is something better than a custom nginx or haproxy setup, but that can be at least a way to get something in place.

[gdm85]

@inthecloud247 sorry but I think we have diverging views on who is the target user of docker. For me, it's the devops/engineer, so a person that already has full (root) trust on the host system.

If in your case it's different please tell me where in Docker design/documentation it is pointed out that you can use Docker without full trust on host system, because I haven't seen it so far (although obviously would be interesting to know about this).

I was mentioning that you ought write such wrapper because by design Docker does not expect nothing less than full trust (AFAIK), and of course you can desire more granular control but it has to be proposed as a feature request and then if it's in line with the goal and design principles of the project the devs might start work on it, e.g. it's not a bug.

[cnf]

as @cpuguy83 has mentioned, anyone that has access to the docker socket has FULL access to the host system (and by extension every container on it), docker exec does not give anyone more or less access than is already available. it just makes some things easier.

As such, I doubt the docker people will do something special for docker exec, as the equivalent is already available.

[nathanleclaire]

Specifically with docker exec, the issue is that there may be things that were started in the container via the docker exec command after the container was started. And there isn't any way to really inspect or know what was exec'd in a running container. Leading to instant devops hairball scenarios where production does funny stuff and nobody knows why...

Just chiming in to be "that guy" and say you shouldn't be doing this. Using docker exec to mutate container state just breaks everything that Docker is trying to do (make things repeatable): it should only be used for development and maybe a last resort in production (as in, if everything's on fire: not as a normal operation- even then you should be rebuilding an image and doing docker stop => docker run for those containers ASAP).

[inthecloud247]

@nathanleclaire agreed that ppl shouldn't be using docker exec to mutate container state. But that said, I feel that it's likely that most of the devs I know will be doing this, and I think a lot of sysadmins are going to use this heavily by building up containers on startup using a bunch of external shell scripts run by docker exec.

After reading through everyone's feedback, I think that there may be a way to make everyone fairly happy without requiring major modifications. So I would propose adding to a docker metadata equivalent of a "time last-modified" metadata common on filesystems. This wouldn't require additional logging or filtering.

The current state metadata is like this:

    "State": {
        "ExitCode": 0,
        "FinishedAt": "0001-01-01T00:00:00Z",
        "Paused": false,
        "Pid": 19967,
        "Restarting": false,
        "Running": true,
        "StartedAt": "2014-10-20T10:53:50.649532096Z"
    },

So with my proposal here, we could have a new state datapoint for "ModifiedAt":

    "State": {
        "ExitCode": 0,
        "FinishedAt": "0001-01-01T00:00:00Z",
        "Paused": false,
        "Pid": 19967,
        "Restarting": false,
        "Running": true,
        "StartedAt": "2014-10-20T10:53:50.649532096Z",
        "ModifiedAt": "2014-10-20T10:55:50.649532096Z"
    },

On container start, ModifiedAt would be set to the same at StartedAt. And docker exec calls on a running container would update the ModifiedAt field.

thoughts? @jpetazzo @crosbymichael smells ok? :-)

btw, thanks for the feedback here. It's good to get clarity on where the current community thinking is holding. Glad I asked before opening a pull request lol.

EDIT: moved into new proposal #8768 . discussion / feedback on this should go there.

[ekkis]

my two pence on the issue: anyone running on a hosted situation is at the mercy of the sysadmins. I have root access to my hosts but so do the admins of the hosting company, which means they can tinker with my stuff. if you're running in an untrusted environment that is very much not good

[bonespiked]

I think the core request is to find a way to programmatically prevent external modification of running containers. Yes, if you can run containers, you are already 'inside the henhouse'. I think that having a mechanism that does more than saying "well, you weren't supposed to modify it" as an option, particularly in a production environment would improve security.

[cpuguy83]

This is supported via authz plugins.
https://docs.docker.com/engine/extend/plugins_authorization/