News for hackers. Stuff that matters.
Re:Dockerfile Security Best Practices by cpuguy83 on Thursday October 15, 2020 @12:26AM (#24784928)
I'm a Docker maintainer and have been for years.

The default is terrible. It got into 1.0 and just got stuck there :(

Changing defaults on such widely used software is, unfortunately, hard.

For whatever reason Docker prepends rules. There are things you can do to add your own filtering (Docker forwards to the "DOCKER-USER" chain where you can put your rules), but it requires people to know what is happening I order to use it securely.

It would be really nice to be in a more secure situation by default... open to suggestions and contributions for Docker 21.

Re:Dockerfile Security Best Practices by Godel_unicode on Thursday October 15, 2020 @12:44AM (#24785032)
Have you considered at least logging to the terminal on container start whenever a port gets exposed to the internet because of a 3306:3306 (i.e. without an explicit ip to bind to)? Part of the issue seems to be that people haven't read the docs and so don't really understand what that snippet they copied from that helpful blog, you know, does
Re:Dockerfile Security Best Practices by cpuguy83 on Thursday October 15, 2020 @05:14PM (#24794072)
I like this idea. I believe we already have a mechanism for warning on container create.

The nice thing is admins can already define a default value that the eninge will use to bind to (when no address is specified on -p). Warning can point users to that setting.

Re:Dockerfile Security Best Practices by cpuguy83 on Thursday October 15, 2020 @05:15PM (#24794081)
I do worry a bit about noise, though.
Re:Dockerfile Security Best Practices by Godel_unicode on Thursday October 15, 2020 @09:10PM (#24796334)
Perhaps make it easily quieted in the settings, and some kind of backoff between warnings? I definitely agree that it could be too much, on busy development systems especially!
Re:Dockerfile Security Best Practices by acdha on Thursday October 15, 2020 @03:31PM (#24792786)
That's definitely a tricky situation to be in since you'll inevitably get someone complaining that an upgrade broke something they depend on.

I like Godel_unicode's suggestion of logging and that could probably done in a stronger manner if there was some point (post-install, maybe starting a container) where it checked the existing rules and used a more prominent warning when there are existing rules which would prevent a container which would be reachable now from being reachable in the future. Given how widely Docker is used, I'd assume that'd be the kind of thing you'd need to add as a warning for multiple releases before even doing something like having it switch to a more secure default on new install.

Re:Dockerfile Security Best Practices by antonvs on Thursday October 15, 2020 @10:31AM (#24789004)
What about a "docker secure" command which updates the configuration to a more secure default?

This also raises the possibility of different security profiles like dev, prod, etc.

A default Docker install would be documented as being for development, and you run "docker secure" to change that for other environments.

Re:Dockerfile Security Best Practices by cpuguy83 on Thursday October 15, 2020 @05:12PM (#24794044)
I like the general idea, but ultimately suffers the same problem in that people have to know about it. There actually is a setting to set the default bind address already.
Re:Dockerfile Security Best Practices by antonvs on Friday October 16, 2020 @04:11PM (#24804579)
If you can't change the default because of backwards compatibility and inertia, you can at least provide a well-documented, recommended, easy way of fixing the default.

Is there official documentation that tells users to set the default bind address as a best practice?

I wasn't thinking so much of just changing one setting, but rather having a way to easily reconfigure an installation to set multiple settings to improve security.

In addition, elevating this to the status of a command and documenting it as a best practice helps spread awareness.