Digg this story   Add to del.icio.us  
Cleanliness next to Rootliness
Daniel Hanson, 2005-04-27

Linspire's arguments to only run a desktop system as root has everything to do with privilege seperation, privilege escalation, and some design choices made along the way.

"But nothing unclean will enter it, nor anyone who practices abomination or falsehood, but only those who are written in the Lamb's book of life." -- Revelation 21:27

The old saying about cleanliness being next to godliness has a certain resonance in the world I live in every day. What is so appealing about a clean computer system? Why does my Unix co-author Jason Miller seem so obsessed with his "clean" BSD systems? I can tell you that Jason is a pretty paranoid individual, and his desire for cleanliness and purity in his operating system has its roots in paranoia.

An even more appropriate question might be, what is the connection between cleanliness and rootliness (considered godliness in a Unix system)?

A place for everything and everything in its place

The CEO of Linspire, Michael Robertson, recently sounded off in an interview on how useless it is to try and compartmentalize system access on the desktop. While much of the attention that this received in the Unix and Linux community has been hostile, in a sense I can see the attractiveness of his point of view. To quote Robertson,
I defy anybody to tell me why is it more secure to not run as root. Nobody really has a good answer. They say "oh, yeah, it is!", but it really isn't. Here's why: What's the most important thing on your desktop? It's the data. If someone gets access to your libraries or whatever, who cares? Your data is the most precious thing on your computer. And whether you log in as root or log in as user, you have access to that data, technically anyone who's compromising your account has access to your data as well.
I can certainly see the appeal of this line of thinking, and from a limited perspective, Robertson is correct. The data that you create, you have access to. If someone masquerades as you, or to be more precise, they have your access tokens or UID, that person also has access to your data. To protect the contents and context of this data, the only option is really to use cryptography in some way.

To guard against someone being able to access your data (and possibly delete it even if it is encrypted), you are left with one choice. Not only should you not execute any untrusted application, these days you also should not view any untrusted images, you shouldn't browse any untrusted Web sites, you shouldn't chat on any untrusted instant messaging platforms, and, upon further consideration, you probably shouldn't do anything that involves turning your computer on.

What we're really discussing here is privilege separation, and the reason it is important is because it can help ensure that an attacker has much greater difficulty accessing your data without your knowledge. To make use of this ability, it takes a good system design -- but if you don't at least try to use privilege separation, the rest your effort is futile. One of the benefits to having a place for everything is that when something goes wrong, it is confined in what it can do. If I have a large number of vegetables, and some start to rot, that rot can spread rapidly unless they are placed in their own containers. Placing them in their own containers facilitates the identification of the spoiled vegetables. The same principle works for applications.

In a functioning computer system, certain critical system functions must be trusted: memory access, raw disk access, and raw access to the network. If everything runs at the same privilege level, this trust is gone. Running everything as root means that there are no limits for hostile code run on the machine. That hostile code may have been run as part of a Web browsing session, downloaded from an email, or acquired from any number of other sources. Let me repeat, code run as root usually has no limits. This is why rootkits are so dangerous and this is exactly how they work: they suppress or otherwise manipulate the information being supplied to or from aspects of the kernel. In order to do this they have to operate with no limits. (Please note, I am aware of systems that limit what root can do, and as yet, they are not widespread enough to alter my argument). The danger with a rootkit isn't that it compromises your data, it's that you have no way of knowing that your data has been compromised.

Robertson goes on to state that by running everything as root, grandma can now change her wallpaper without problem (why the desktop display settings for a user account would be root controlled is never really discussed by him, however). Then he defies anyone to show why running a complete system as root is a bad idea. Well, here goes: Linux.RST.B.

Is a system really clean if everything is in the same big pile?

Running everything as root is an expedient way to make a seamless interaction for the end user. Robertson is attempting to undermine any security arguments that are in opposition to the design choices that his company has made while developing a desktop operating system. I feel it is disingenuous for him to boil a complex issue such as security down into a one dimensional concept of "access to data."

All the benefits you gain by running everything as root can be gained in other ways by spending more time designing the system. The problem is that this extra design really does take time and money, and Linspire has chosen to offer the most seamless user experience with the least investment of time. Please note that I don't believe that Linspire is a bad company because they have made this choice; instead I believe that they are being disingenuous by not discussing in the most open fashion the tradeoffs that they have made.

An interesting operating system that attempts to do a better job of separating out system privileges, administrative privileges and user privileges is Apple's Macintosh OS X. OS X disables the root user in the underlying Unix system, but allows the privileged administrative user to administer the system. There is room for improvements with this approach, but I argue that it is a more secure road to travel than the one Linspire seems to be advocating. (Interested readers and zealous Mac users might wish to know that I haven't changed my opinions about other aspects of the Apple approach to security and I am still a non-believer in the Apples are immune to viruses argument).

Meanwhile, back in the real world

Suppose that in the real world that we live in, there really is no difference between running everything as root and running everything in separate privilege containers. In the real world we clearly still have a problem, thanks to a little class of vulnerability called, "Local privilege escalation" or kernel 0-day. Recall how I pointed to Macintosh OS X as an example of have a better designed privilege separation system, and then watch how to bypass all that critical and expensive design time with one short step.

If privilege separation is only good until the next privilege escalation vulnerability, what is a paranoid person to do? Should we not wear seatbelts in a car simply because there are times when you might die even if you wear them? What about insisting on aircraft inspections despite the fact that some problems go undetected? Why would we design a system that we KNOW has no protections rather than one with protection that are not perfect?

I choose to live in the real world, but strive for the ideal world. I would like to believe that software will improve over time, that slowly privilege escalation vulnerabilities will become rare as programmers learn to recognize the situations that create them.

Maybe I will die hoping for a computing paradise that will never arrive, but I delude myself into believing that there is some nobility in the struggle.

Daniel Hanson manages the Focus Incidents area of SecurityFocus as well as the Incidents mailing list.
    Digg this story   Add to del.icio.us  
Comments Mode:
Amen! 2005-04-27
Cleanliness next to Rootliness 2005-04-28
Cleanliness next to Rootliness 2005-04-28
Todd Knarr (2 replies)
Cleanliness next to Rootliness 2005-04-28
dph - author
Cleanliness next to Rootliness 2005-05-05
"Most important" - oh no... 2005-05-04


Privacy Statement
Copyright 2010, SecurityFocus