Database security

We have left database security as a more or less untouched topic for too long and I hope to push that forward in the next weeks.

Good practice is to set a proper DB root password as well as add a less privileged account for the actual application. If we go that route we’d need to ask the user for two distinct new passwords or generate those and display to the user. We need a hint that those should be stored in the password manager of choice or written down. But as well I feel that we should prepare a detailed wiki article on how to reset the DB root password on all distros just in case people have locked themselves out. Who’s up for that?

I intend to use mysql_secure_installation command as well.

In case people choose to let the installer generate a password I’d prefer to set a semi complex password (numbers, lower case, upper case and a couple special characters) but only 8 characters in length. That way we have a chance that people actually note it down. -> Not sure if that’s a great idea, open for discussion.

I’ll probably need to setup a whole park of VMs to test the changes before we actually release this to the public. Otherwise we’ll have a massive storm of questions in the forums and installations to fix up later on I fear. This is because we have different versions of MySQL/MariaDB in the distros and some behave differently as far as I know. We have @Wayne-Workman’s awesome installer test park running but I have a feeling that we won’t cover it all with that. We need fresh install testing but even more we need testing on upgrade installations (one with empty root password and another one with a password already set). I think I can do a fair bit of that in my VM test setup I have on my working laptop using snapshots. But I am not sure I can do it for all distros. @Moderators@Testers Anyone around who’d do the tests for one or the other distro?

Please post here if you have more ideas on this or if I have left out something important!!

Issues that we might run into as setting the password has changed several times in different versions of MySQL and MariaDB:

I’ll definitely pick this up again in the next days and weeks. Just had so many other things around and couldn’t find the time for this.

As well on github we have someone reporting a related issue. The installer doesn’t care about you typing in a password. It just wouldn’t use this when setting up the database in a lot of cases. Will be working on this as well: https://github.com/FOGProject/fogproject/issues/319

@developers@moderators I was able to get the daily installation tests to test upgrading from FOG 1.5.5. Mostly this is going good, but 1.5.5 didn’t install correctly on Fedora 30 or RHEL7. Those two are totally jacked, but everything else seems to be working right.

It’s probably going to be two weeks or longer before I can adjust the daily tests - I’m super busy this weekend, next week, and vacation is the week after. But I’m pretty confident I can test upgrades. At least upgrading from the last release.

I’ve thought about testing upgrades, I don’t think it’d be too tough. Basically, I’d add 6 more instances - all the same OSs already being tested. But I’d install the last release of FOG on them - and then snapshot.
That way, the original 6 still have clean snapshots and would be labeled as ‘clean’, and the other 6 would have a fog installation on them and be labeled as ‘upgrade’. All the other commands remain the same I think.

For the root password in the db. By default pick a random password and then give the user the option to change it, akin to how the fog installer picks the network adapter, but then lets the user change it. The fog installer should warn the user to write this password down someplace because its important and would be needed for database repair.

The fogdb user’s password should be managed like the fogproject linux user’s password. Its owned and set by the fog installer, but is recorded in the .fogsettings file. If the fogdb user’s owns the fog db, then there really is never a reason to use the db’s root user any more.

For the db’s root user password resets, I don’t think we need to reinvent the wheel here. Maybe provide a wiki with examples for the big three centos, debian, and ubuntu (current minus 2 releases if there is any changes) and then say for other distros they will need to google the answer. Lets not kill our selves trying to be all things to everyone. If the fog admin has deviated from the recommended distros then they should have enough skills to reset the root password. Its not that complicated.