Superuser Containment: The Cost of Doing Nothing

The idea of “superuser privileges” encompasses those with the highest level of access in the network OS. For individual Microsoft Windows systems, that user is Administrator. For Microsoft Windows systems connected into an Active Directory (AD) domain, the Domain Administrator account is added to the list. For many Linux and UNIX systems, the user is root.
One of the biggest problems with these accounts is with their native architecture. In the UNIX world, the only user with default superuser privileges is the root account. To complete a system-level task in UNIX, the operator must login with their standard credentials and elevate themselves to root. This means that the root user along with its password is often shared among all administrators performing administrative duties. A similar problem is true in Microsoft Windows where Windows administrators use their Domain Administrator-level permissions as their standard login.
The sharing of these top-level accesses is in violation of the computing principle of least privilege, which is “the computing concept of access or functionality within an operating system whereby a user or program is granted minimum possible privileges to permit an action. In doing so, the operating system as a whole is not exposed to unwarranted or excessive actions that may cause damage or promote further negative actions”( Source: http://en.wikipedia.org/wiki/Least_privilege). The native architecture of these OSs provides complete and total access to the superuser. The superuser can effectively perform any action on any data object within that superuser’s scope of management. Thus, sensitive, classified, or inappropriate information housed within the superuser’s network is automatically and always available to the superuser—whether they should have access to that information or not.
To best visualize this problem, let’s take a look at an example you may already be seeing today within your network environment. In this example, the IT department has implemented a database containing highly sensitive information. The information contained within this database is in fact so sensitive that the systems administrators in IT cannot have access to view or modify the information. IT still needs to manage the system: Maintain its hardware and software baseline, apply patches, deal with troubleshooting issues, and so on. But the data within that database should not be seen by them.
Figure 1 deconstructs the various components of this database system into a stacked series of data blocks. Each data block in Figure 1 relies on information made up of those below it. The summation of all these elements makes up our example system in question.
You can see in our example that the highly sensitive Application Data within our database resides on top of the Database Application. That database application contains the executable files and configurations that make up the database itself.
Alongside the data are the Application Log Data used in troubleshooting the database. Portions of that log data are also used during restore operations to roll up unwritten transactions occurring immediately prior to a failure. This introduces a problem because incorporated with the troubleshooting information could be portions of the sensitive information within the database itself.
Immediately below the database application are our Native File System and O/S Log Data, which all reside on top of the Core O/S. In our example, individuals with uncontained superuser access to this system automatically have access to each data block in our diagram. Due to the architecture of how privileges are granted in this OS, it is virtually impossible to remove data access from superusers short of removing superuser access altogether.
This inability to granularize permissions at the superuser level is an issue along a series of axes. Let’s take a look at each of those in turn.