Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase security by adding possibility to have 'root'@'localhost' and not only 'root'@'%' #231

Closed
MorganLindqvist opened this issue Oct 29, 2016 · 10 comments · Fixed by #249

Comments

@MorganLindqvist
Copy link

Hi,

I would like to increase the security in my mySQL docker installation by not allowing root to login from any computer that can access the port on the host.

I am used to that root only is allowed to login from localhost. Since we are talking about a docker container here I guess there can be arguments that one does not in all installations have access to the container itself and need to act as root from another computer.

I would however prefer if there was an option not to have root@% as the default and not the only option when installing.

If you have access to the computer hosting the docker container one can use the command "docker exec -it mysql mysql -u root -p" to run a mySQL client and access the server from localhost.

I was looking into adding files to the /docker-entrypoint-initdb.d/ folder but these files are executed before the commands related to the option MYSQL_ONETIME_PASSWORD is executed. Since the later rely on 'root'@'%' it is not possible to change from @'%' to @'localhost' in a script in this folder.

I see a number of ways to fix this.

  1. Add an option MYSQL_ROOT_HOST that have a default value of '%' (for backwards compatibility) but gives the user of the container the option to set it to 'localhost' or possibly another name that is used by the computer connecting to the docker container.

  2. Move the handling of the MYSQL_ONETIME_PASSWORD above the handling of docker-entrypoint-initdb.d. A user can then add .sql commands to it that changes the '%' for root to 'localhost' or whatever he/she prefers.

I am sure there are more options.

My proposal would be #1 above since I think this will highlight the possible security risk with having 'root'@'%' and give the user of the container the option to increase the security.

If we agree on a way forward I can create a pull-request.

/Morgan

@ltangvald
Copy link
Collaborator

I think 1) sounds pretty good, with the default being %, as it should not require a big change

@MorganLindqvist
Copy link
Author

OK, i will start implementing 1) above.

Should I also write some text for the mysql page on hub.docker.com or do you do that when releasing a new version?

@ltangvald
Copy link
Collaborator

Having a blurb ready to describe the new variable would be good, yeah.
@yosifkit
@tianon
What do you think about this?

@ltangvald
Copy link
Collaborator

We've made a version of this for upstream's own image: mysql@6fbb227
Biggest change is that by default it only allows localhost connections, implementation is a bit fiddly, because since the script logs in as root@localhost, it can't delete and recreate that same user. We instead change so it doesn't delete root@localhost to begin with, but simply changes the password, and if MYSQL_ROOT_HOST is set it creates an extra root account for that host.

@tianon
Copy link
Member

tianon commented Nov 22, 2016

Wow, not sure how this one got missed for 22 days, sorry 😞

I'm a bit on the fence, but leaning towards +1 more than -1; it's difficult to know the IP address of your connecting containers in advance (or what their reverse DNS will be, if that's manually re-enabled), but this can save users who know what they're doing from having to munge the % value after the fact, so seems simple enough. 😄

@ltangvald
Copy link
Collaborator

We could do it as the original proposal suggests and keep % as the default for this image to avoid giving existing users any unpleasant surprises. Most important is to have the option to make it more secure in a simple way.

@yosifkit
Copy link
Member

I am also on the fence. If the problem for munging the host of the root user in your own script from initdb.d is the MYSQL_ONETIME_PASSWORD handling, then why not just set password expire from the same root user changing script? The reason for setting the expire after the initdb.d scripts is so that it doesn't force a change password on the first script.

On the other hand I see how an easier way to secure the root user would be beneficial. I just worry about adding too many environment variables to the image and how many more variables does this "open the floodgates" for.

@ltangvald
Copy link
Collaborator

Well, part of the issue is that currently our entrypoint script reverts a security measure in the server; only allowing root access from localhost. The containerization means this isn't as big an issue as it would be normally, but it's not obvious that it happens, so there's a real chance of users not noticing.

So giving an explicit way of changing it gives two benefits: giving a simple, standard way of making the container more secure, and also raising a flag through documentation that it works the way it works (last part doesn't really need the actual functionality, though).

@skriesch
Copy link

skriesch commented Dec 7, 2016

Hello. I found this issue in the mariadb docker image, too.
I mean, you need root access on localhost and a special user for the application server. I want to use it for Wordpress, as an example.
It isn't secure using % for root and application users. Everybody can come into your database (with URL of the application, too). I thought about if-else for the application host. You can add your own IP address, use localhost or %. You can choose what you like then.

I sent the referenced issue and Pull Request.

@ltangvald
Copy link
Collaborator

I do think it would be a good idea to make this an explicit option, since it's security-related and a change from the default behavior of other MySQL packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants