Why SQL Server Shouldn’t Run as Root on Linux

So more than one person contacted me about my last post and stated that they didn’t see a problem with SQL Server on Linux running as the root user.

Me:

Although enhancements have changed Windows installations for applications to run with a unique user, I created a mssql OS user even back on SQL Server 2000 on Windows as I had a tendency to use similar security practices for all database platforms as a multi-platform DBA.  With that being said-  yes, it introduced complexity, but it was for a reason: users should be restricted to the least amount of privileges required.  To grant any application or database “God” powers on a host is akin to granting DBA to every user in the database, but at the host level.  As important as security is to DBAs INSIDE the database, it should be just as important to us OUTSIDE of it on the host it resides on.

Security is important and has become more complex with the increase of security breaches and introduction of the cloud.  One of the most simple ways to do this is to ensure that all application owners on a host are granted only the privileges they require.  The application user should only utilize SUDO, stick bit, iptables, SUID, SGID and proper group creation/allocation if and when required.

SQL Server As Root

As an example, let’s say that SQL Server is owned by root on a Linux machine and its a standard process for this system to still load data via Excel spreadsheets since it’s OS migration to Linux.  A hacker has discovered this and builds malware to attach to the excel spreadsheet and as the files are owned by the same owner as SQL Server, the malware is able to take advantage of the vulnerability, running scripts on the host as root. If SQL Server had been installed as the OS user mssql, with limited privileges and proper group affiliation, this type of attack could be isolated and impact lessened.

Linux administrators will consistently demand you justify why you need to run anything as root.  No matter if it’s to update files, create files, modify applications or even execute system tasks, but by having a proper user/group configuration will:

1. Have the ability to track via an audit who has switched over to super user.
2. be more likely to eliminate human mistakes by executing catastrophic commands.
3. Simplify identifying what processes are part of an application stack
4. provides a second layer of security that could save the company from becoming the next security breach.
5. Limits the amount of data the application is privy to on the host.

Do It Right, Don’t Do It Twice

Create a proper MSSQL OS User on Linux and create a DBA and SQLINSTALL group.  As Microsoft matures its SQL Server offering on Linux, features are going to increase and be enhanced.  Microsoft will embrace mature practices, so get ahead of the game and start now, building proper security from the beginning.