[debian-mysql] MySQL "hardening?"

[Clint Byrum]

Excerpts from Ralf G. R. Bergs's message of 2015-04-04 04:54:28 -0700:
> Hi Otto.
> 
> Thank you for your response and the info given therein.
> 
> On 2015-04-03 20:03 , Otto Kekäläinen wrote:
> > In Debian we used to apply the hardening-wrapper package/tool in
> > mysql-5.5 and mariadb-5.5 packages until if was deprecated in the
> > Debian policy. In mysql-5.6 and mariadb-10.0 we are using the new
> > compiler flags based hardening. See e.g. the rules file
> > https://github.com/ottok/mariadb-10.0/blob/master/debian/rules
> To be honest I didn't even think about that kind of (build) hardening,
> but of course it is a benefit to "defend" against potential attacks.
> 
> What I was thinking about -- and sorry for not being more specific -- is
> "config hardening" in a way that "dangerous" features might be disabled
> by default (e. g. might only listen on Unix domain socket and not TCP
> socket by default, or /if/ TCP socket is active by default the daemon
> might only bind to the loopback interface), rate limiting and other
> usage restrictions (ulimit?) might be enabled for the pre-defined MySQL
> database users or the MySQL system user to prevent DoS attacks, etc.
> 
> So basically config changes which can serve to increase security,
> compared to the "stock" MySQL config that comes from upstream.
> 

NOBODY expects (the spanish inquisition? ;) MySQL to work well for
anything except the most basic duty without tuning it. Upstream or Debian
can't choose buffer sizes, connection limits, and data safety options
that will work for any significant number of users. The defaults are
whatever MySQL or MariaDB ships, with a few extra bits thrown in. Namely
we do only listen on 127.0.0.1 in the default config. We also ship a
mature AppArmor profile, so if you turn on AppArmor you'll get some
additional restrictions.

Everything that happens once you've connected to MySQL is mostly out of
our hands. We do make users for doing system maintenance, but they are
basically only accessible by root. All the other users will be in your
database because you put them there, and I suggest auditing the entire
'mysql' database with that in mind. Privileges in MySQL can be complicated
to get right, and a lot of people just throw "GRANT ALL PRIVILEGES ON *.*
TO 'bob'" and forget that they've just made a grave mistake.

> I assume that you can't (and probably don't even want to) make any
> statements re. the "stock" config, so I will search on the upstream
> MySQL site as well.
> > If you are an expert in this area or even just somebody with basic
> > skills and have time to research it, I am sure everybody would be glad
> > to get contributions on how to improve the current situation.
> I'm always a strong supporter of giving back to the community, but
> unfortunately I'm currently not in the position to do so. On the
> contrary I need support myself because I'm undergoing a security
> assessment/audit and must "prove" that our systems are secure. ;-)
> 

So, IMO no packager can provide anything that is really "hardened" and
is generically consumable. We can of course lock things down that are
obvious, and have sane default configurations that don't leave gaping
holes. But I would still spend most of the time reviewing the entire
configuration given the site specific use case.

I wish you luck in your endeavor. I hope we've helped. :)