Any php program in a linked container can read the mysql root password

[jlj]

Note: this is a copy of a message about this issue that I wrote as a comment to docker issue #5169 (closed) see moby/moby#5169 (comment)

Although the docker documentation now clearly includes a warning about env variables being propagated to linked containers, this still looks like a real security problem to me, because many images, including official images pass secret information though env variables, and there still doesn't seem to be a good way to pass a private variable to a container at runtime.

This can be illustrated by a very simple php / mysql application using a database container,using the official mariadb image, linked with a php container based on the official php image.

The result is simply that any php program has access to the mysql root password via the env variables:

And really, this is not desirable!

Ok, this could be considered as a bug of the mariadb image and I will also enter it as such...
But my real feeling is that it looks more like a general docker issue.

[yosifkit]

This is how we can just --link an sql database to a wordpress container and it just works.

One possible solution is to only use the env for setup and then use a second container to --link to the database and setup the real users, changing the root password. That would make the envs not matter after initial setup, but then you have to configure all of your connecting containers with their users and passwords.

[tianon]

You could also use "initdb" (or just a normal connection after initial setup) to change the root password. We have to have _something_ to initialize the password to, and it can't really be interactive, so we don't have a lot of options here.

[jlj]

I agree that you don't have many options here for setting the mysql root password.

However, having the db root password visible in clear in the linked containers is a major security issue and makes completely meaningless the creation of other restricted users (like the one associated to the optional default database in the image).

Therefore, even if it is far from perfect, a solution for this could be to generate a random password when MYSQL_ROOT_PASSWORD is not specified on the command line, and to echo it in the container's log.

This means replacing in docker file-entrypoint.sh

    if [ ! -d "$DATADIR/mysql" ]; then
        if [ -z "$MYSQL_ROOT_PASSWORD" -a -z "$MYSQL_ALLOW_EMPTY_PASSWORD" ]; then
            echo >&2 'error: database is uninitialized and MYSQL_ROOT_PASSWORD not set'
            echo >&2 '  Did you forget to add -e MYSQL_ROOT_PASSWORD=... ?'
            exit 1
        fi

by

    if [ ! -d "$DATADIR/mysql" ]; then
        if [ -z "$MYSQL_ROOT_PASSWORD" -a -z "$MYSQL_ALLOW_EMPTY_PASSWORD" ]; then
            MYSQL_ROOT_PASSWORD=$(pwgen -s 12 1)

            echo "========================================================================"
            echo "  Generated MYSQL_ROOT_PASSWORD for this Docker container: $MYSQL_ROOT_PASSWORD"
            echo "========================================================================"
        fi

This has the advantage of keeping the compatibility with the existing command line, and running mariadb as docker run --name database -d mariadb has the expected result, i.e. that the root password is not visible anymore as an environment variable in a linked php-based container.

If you are inline with this proposal, I can create a pull request; otherwise I'll just use it for my own needs... :-)

[skyred]

I just realized this security problem today. This problem is that the official docker mariadb library ships with a pretty big security hole as default. I cannot agree with #21 (comment) that conviennce takes higher priority than security in this case.

I am proposing that we simply make MYSQL_ROOT_PASSWORD optional. This would make the two use cases work:

1. When people want " just --link an sql database to a wordpress container", they can use MYSQL_ROOT_PASSWORD env variable.
2. When people want take full advantage of MySQL permissions & roles, they need to get in mariadb instance after docker run to initialize their own root password. We can use the code from Any php program in a linked container can read the mysql root password #21 (comment)

[jlj]

Please be aware that this root password leak issue is not specific to the mariadb docker image. For example I checked the mysql official image and it presents the exact same issue (which is not surprising, since both mariadb and mysql have almost identical Dockerfiles).

[thaJeztah]

I opened up an issue in docker a while ago to design/write up alternatives for managing "secrets"; see moby/moby#13490. The current behavior is "by design", and is useful for "automatic" configuration of linked containers, but I fully agree that leaking these env-vars to linked containers is far from ideal.

[skyred]

@thaJeztah please enlighten me what's the downside of making MYSQL_ROOT_PASSWORD optional? The "automatic" configuration can still work as before, right?

[thaJeztah]

@skyred sorry, just wanted to add a reference to general optimizations that could be made, w.r.t;

Although the docker documentation now clearly includes a warning about env variables being propagated to linked containers, this still looks like a real security problem to me

I agree on making the MYSQL_ROOT_PASSWORD optional.

[iBobik]

Make MYSQL_ROOT_PASSWORD optional it good solution.

Don't forgot to document it in README, to make everybody understand that they should use MYSQL_ROOT_PASSWORD only if they know what they do.

[yosifkit]

MYSQL_ROOT_PASSWORD is optional, just set MYSQL_ALLOW_EMPTY_PASSWORD to something non-empty. I'll be updating the docs for the mariadb image to reflect this; MYSQL_ALLOW_EMPTY_PASSWORD has been available since #4 😳.

[iBobik]

Nice, going to use it.

But why two variables for use case, where one is enough and more intuitive?

Jan Pobořil

2015-09-23 18:50 GMT-05:00 yosifkit notifications@github.com:

MYSQL_ROOT_PASSWORD is optional, just set MYSQL_ALLOW_EMPTY_PASSWORD to
something non-empty. I'll be updating the docs for the mariadb image to
reflect this; MYSQL_ALLOW_EMPTY_PASSWORD has been available since #4
#4 [image: 😳].

—
Reply to this email directly or view it on GitHub
#21 (comment)
.

[jlj]

@yosifkit Sorry, but MYSQL_ALLOW_EMPTY_PASSWORD can hardly be proposed a solution for the security problem here: replacing make sql root password public for every linked container by do not set a sql root password does not seem like a real improvement to me.

What would rather be needed is a way to set the sql root password in such a way that it is not accessible to other linked containers.

[md5]

@jlj This repo isn't really the place to debate the need for such a feature. Looks like you've already commented on moby/moby#5169, which is the most recent discussion I've found specifically dealing with that topic. As far as I know the "links v2" proposal mentioned in that issue never happened. This comment mentions that a replacement proposal was going to be made public at some point, but I don't recall ever seeing one. Others may know better. This issue is also a good overview of the past proposals and possible future roadmap for handling secrets in Docker: moby/moby#13490

[md5]

@jlj I also see now that you're already aware of moby/moby#13490

[jlj]

@md5 The point of this issue is not to debate about docker features. Actually, the fact that, if using this official mariadb image, any php program running in a separate-but-linked container has a direct clear access to the SQL root password looks like a serious security concern to me.

Additionally, and this may seem naive, I thought that official docker image were supposed to be representative of the best practices, e.g. the ones listed in the post you mentioned moby/moby#13490. And if the people in charge of this repo consider that the mysql root password shall not be considered as a secret ,and thus can be put in an environment variable without any inconvenience, this is not a problem for me (I just won't use this image), but it seems reasonable that other users are aware of this when selecting docker images for building their system. :-(