The Importance of Privilege Separation


One of the more important concepts of computer security that is a function of operating system design is the concept of privilege separation.

Real privilege separation is a design decision baked into an operating system at the architectural level, as an intrinsic part of the OS rather than a feature added on later. It is that state of system behavior where the OS recognizes differences between user accounts — and between what actions they are able to perform — and is designed in such a way as to make it effectively impossible for one account to directly perform actions prohibited to it but potentially allowed for other accounts.

There are often work-arounds for privilege separation, allowing a given user account to achieve much the same effects as violating privilege separation. Examples include the (in some circles, notorious) setuid and setgid file permissions on Unix systems. These are work-arounds, however, and not true violations of privilege separation, because setting a file's setuid or setgid permission is essentially an act of delegation, where an account that already has a given privilege can delegate that privilege to other accounts under limited circumstances. This can be a very dangerous thing to do, because a process with too much flexibility in terms of what it can do on the system, when it has a setuid permission and is executable by other accounts, might end up essentially granting other privileges than those intended the user intended to grant. It is not a violation of the principle of privilege separation in the system's design because, among a given account's privileges on a standard Unix system, it has the power of delegating certain privileges to others.

Another such Unix delegation work-around is sudo, a tool developed for the purpose of granting the ability to perform specific administrative tasks to generally non-administrative user accounts. Just as with setuid and setgid permissions, sudo must be used with care to avoid accidentally granting much more power to a non-administrative user account than intended.

By contrast with Unix systems, which have intrinsic privilege separation protections designed into their architectures and provide work-arounds that can be used to allow special cases of crossing the privilege barrier when needed, there is the example of Microsoft Windows. This is an operating system originally built on a single-user model, where privilege separation was not even a meaningful concept because there was only one user account to have any privileges. Further development of the OS began to accomodate the concept of multiple user accounts over the years, with increasing ability to maintain separate user environment settings and files.

Because the core architecture of the system was not reworked to include privilege separation as a foundational assumption of the entire OS, privilege separation became a matter of superficial features that attempt to intercept any actions a given account attempts to perform that the MS Windows developers in Redmond, Washington have decided it should not be allowed to complete. Rather than starting from a basis of denial of permission, where everything has its realm of privilege and user accounts are limited within those realms, MS Windows starts from a basis of allowance of permission, where every user account can do everything. It then addresses privilege separation matters as the developers realize they need addressing. The primary problem with this approach is that there are, in effect, infinite possibilities for specific cases of privilege escalation, where one user account achieves the ability to accomplish something that should be reserved to a different account, without that other account's delegation of the privilege in question.

Failures of privilege separation are to blame for many of the ills of computer security today. Many viruses and worms would be stopped in their tracks if they were prevented by architectural privilege separation from infecting any files that the user account that executed the malware should not be able to touch, or from propagating itself by taking control of networking and filesystem access capabilities that the user account should not be able to control. Privilege escalation vulnerabilities allow malicious security crackers to gain administrative control of systems, so they can install rootkits and essentially do whatever they like to the software running on these systems, after having first gotten a foot in the door via what should be an unimportant network application executed by what should be an unprivileged user account.

Applications, as well as operating systems, can avail themselves of privilege separation for security purposes. For instance, an application that forks itself into several separate processes that each manage separate tasks the application must accomplish, and only allows the separate processes to communicate through controlled vectors such as network sockets, can ensure that a compromise of one part of the application will not be able to easily affect the other parts.

Many applications are designed to take advantage of an operating system's privilege separation architecture to ensure they do not pose a significant security threat to the rest of the system even if they are compromised, too. For instance, many server daemons on Unix systems need to be started by the root account to gain access to network ports and other capabilities that are typically prohibited to unprivileged user accounts. Once started, however, such daemons may "drop root", assuming the permissions of a new user account further down the privileges chain. Once it has assumed those permissions, it can only access what it delegated to itself before dropping root, and no longer has sufficient permissions to change what user account controls the process, thus ensuring it cannot escalate its own permissions up to those of the root account.

Designing software that separates privileges at an architectural level, so that a failure of some superficial feature cannot circumvent that privilege separation, and selecting software (such as OSes like FreeBSD) that implements privilege separation at an architectural level when choosing what software to use instead of selecting something that offers little or no architectural privilege separation support at all (such as OSes like MS Windows), are among the key concerns any security conscious computer user should consider. It is fundamental to not just mitigating, but often entirely preventing, much of the damage malicious security crackers currently do in the world.





  1. I know that your statements about Windows are 100% true of the old Win 3.1 – Me line, but are you sure that they are true for the NT – 2008/Vista/7 line? After all, that codebase was originally developed with IBM (IBM's half became OS/2 after the partnership dissolved), who had a ton of UNIX and mainframe experience then, and the big player on the NT team was the VMS creator.

    To me, the big concern along these lines in the NT series are the "System" and "Network Service" accounts. I am hardly an expert by any means in this realm, but it seems to me that these are effectively root, but unlike root, no one can actually logon as these accounts; the only way to use them is to start a process as the account. Which, in theory, can only be performed by an administrative user anyways.

    Of course, it may very well be that this is exactly your point, in that the NT series relies on far too many things running as System or Network Service, and many of those items have proven themselves vulnerable to attack.

    All the same, I'd really like to see you expand a bit on the specifics of the Windows issues, so that folks can learn what to do about it. After all, it's perfectly possible in Windows to change which accounts these services run as. Maybe, all that is really needed to get an NT series Windows OS truly locked down, is for someone to compile a list of permissions that each and every default service truly needs, and write a script that creates a user with those precise permissions and tell the appropriate service to run with the new account? I know, that's a monumental task for anyone outside of Microsoft itself, and even with full access to the Windows codebase, it's a tall order.

    All the same, it seems to me that the weakness with seperation of priviledges on NT series Windows is not the base OS architecture itself, but the baked-in and nearly the base OS level reliance on "System" and "Network Service".

    Again, this is really not my field, so please let me know if I'm totally off base, this is just conjecture on my part.


    Justin James · 2009-11-15 · #

  2. I know that your statements about Windows are 100% true of the old Win 3.1 – Me line, but are you sure that they are true for the NT – 2008/Vista/7 line?

    You mean about MS Windows not having true, architectural privilege separation? Yes, I'm sure. The way what passes for privilege separation just gets turned off by WGA is pretty strong evidence that privilege separation is just a bolted-on feature in the NT line.

    Unfortunately, the only way to really secure MS Windows as an end-user rather than a Microsoft developer is to surround it with protective barriers that keep malicious security crackers out, and practice good computer use behavior, so that nobody ever gets a foothold in the first place and gets an opportunity to try to escalate privileges. Even when there are no known privilege escalation vulnerabilities, the vulnerabilities are still there to be exploited, because unless and until something fundamentally changes under the hood your MS Windows system can just deactivate privilege separation when it decides it's time to phone home.

    Architectural privilege separation can't be simply turned off on a running system because, by definition, having the ability to do so means you don't have architectural privilege separation.

    apotheon · 2009-11-15 · #

  3. Interesting post. I wanted to check Jaqui's site for the full details, but I got a 404. The behavior, as summarized in your article, is 100% consistent with what I described above, accounts logging in as "System" or "Network Service", two very creepy accounts! I would love to find the page on Jaqui's site (his site seems to be pretty well messed up, unfortunately… even going to it and trying "Older Entries" is giving a 404). But without seeing the full documentation of the behavior, I don't know if there is a process that is essentially escalating its own priviledges (which would be a sure sign of bolted on security), or if it is just being run as "System" or "Network Service" (which is consistent with typical Windows behavior, and supports the idea of seperated priviledges at the base OS level, but not the "out of the box reality" level).

    I agree that right now, without being able to easily set all of these services to use different accounts with the bare minimum priviledges, Windows security is probably 95% based on fences and user behavior, which is a timebomb.

    That being said, it seems like lately Windows' security has gotten far enough away from the "Swiss cheese" level that it is no longer the lowest hanging fruit (Acrobat and Flash now have that distinction). While that is a backhanded compliment to Microsoft, it still doesn't say much. What really stuns me is that in comparison to companies like Oracle, Microsoft is GREAT about security. Oracle customers are only "safe" because no one is dumb enough to directly expose a database to the outside world… well, no one smart enough to figure out Oracle (I swear, you need a PhD to work that beast) would do that. :)


    Justin James · 2009-11-15 · #

  4. Unfortunately, I don't remember the exact details of what he found, so I can't tell you too much about it in specific. I do recall, though, that it did not involve a process simply running as a "system" or "network service" account. It executed a function that was specifically identified as deactivating a privilege separation check.

    I agree that right now, without being able to easily set all of these services to use different accounts with the bare minimum priviledges, Windows security is probably 95% based on fences and user behavior, which is a timebomb.

    Yeah, that pretty much sums up the fact that — even if the folks in Redmond shoehorned some real privilege separation support into the kernel — there'd still be the problem that all the core userland stuff is designed to be frighteningly promiscuous with permissions and to rely heavily on pseudo-admin accounts, anyway.

    That being said, it seems like lately Windows' security has gotten far enough away from the "Swiss cheese" level that it is no longer the lowest hanging fruit (Acrobat and Flash now have that distinction).

    Good point. I'm not so sure that it's a matter of MS Windows security really getting substantively better, so much as the fact that MS Windows security became more of a moving target, so that gaining the extra sophistication to attack the less dynamic targets of Flash players and PDF readers pays off in terms of overall, long-term investment for malicious security crackers.

    What really stuns me is that in comparison to companies like Oracle, Microsoft is GREAT about security.

    Yeah, what little I know about Oracle secure development practices is shockingly bad. I know much less about it than about MS Windows because of my more limited exposure to Oracle's offerings though, so I get to harp on the devil I know (MS Windows) and mostly neglect the devil I don't (Oracle). I wouldn't want to open my mouth, say something stupid, and end up with a bunch of misinformed readers.

    apotheon · 2009-11-16 · #

Commenting is closed for this article.