Should the requirement of admin privileges be extended?

Question

Seeing this comic from xkcd.com made me thinking:

Is extending the requirement of admin privileges to things such as connecting to the internet, running the web browser, reading browser and other software config files, etc, be something operating system developers and maintainers should be looking forward nowadays?

Or is it the other way around - is it really necessary, in a desktop environment, to have a separate root account nowadays?

I understand the main reason for having a separate admin account isn't to protect your data from being stolen, but preventing software (and other users) from messing with stuff they shouldn't. But shouldn't that protection be extended? Or, on the other hand, wouldn't making programs run under a different, non-admin account or with different privileges instead of making the user log into one be more user-friendly?

Answer 1

The underlying idea of the comic is that separation of user accounts has been designed for mainframes: big computers, shared by many users. In that model, the potential attackers are other users. Account separation is then about protecting users from other users; only the god-like admin account can access everything on the machine, and the administrator has the duty of using his powers to strike down users who try to escape the boundaries of their accounts. System administrators consistently love this model, if only for its inherent ego flattering effect.

However, personal computers are not handled like that. They have a single user who expects to have admin powers on his system. More importantly, the attackers and defenders have changed. The attackers are now remote entities -- non-users from the outside, who will try to enter the machine through various vulnerabilities, in the loose sense of the term (this includes virus on USB keys, hostile scripts on Web pages, remote holes in network stacks...). The assets which the user tries to defend mostly reduce to their "elements of online identities", in particular the set of browser cookies, and their natural extension, the passwords typed by the user.

The comic points out, in a graphical way, that a separate administrator account does absolutely nothing to protect these assets. It does not harm, but it has no added value.

---

What should OS do ? Actually, not much -- it's more a question of what Web browsers should do. Increasingly, the Web browser is the operating system, and what we think of as the OS might have to be renamed "collection of hardware drivers". That's the idea which, for instance, Chrome OS tries to fully explore.

Account separation in mainframes was a damage containment feature. Its purpose is to prevent propagation of evil, and allow the sysadmin to smite at the infidels and trample them into oblivion, namely suppression of account. The gangrenous limb is not saved, but it is severed so that the rest of the organism remains safe, to some extent. How does this translate to the way personal computers are really used ? Remember that what is to protect is, primarily, the set of browser cookies. Damage containment then calls for domain-based sandboxing.

Indeed, cookies are already domain-separated: a server from a given domain may obtain the stored cookies for that domain, and for none other. Similarly, scripts and other browser languages are constrained by the same origin policy which is again domain-based. CSRF, XSS and all the related acronyms in which security practitioners revel are still about the crossing of the domain boundary. This really points at a security model in which each target domain is its own world, and a given browser instance should be contained in a box which allows access to that domain only (only machines in that domain, only cookies from that domain). If one browser instance gets subverted, then, hopefully, the sandbox mechanism will prevent subversion of other browser instances: if your browser-for-Facebook is hacked, your gmail account is still safe.

There is still contention for shared resources. Even if we can get the user to mentally separate his usage modes into separate browser instances (this can be more or less automatic, e.g. by having each set of tabs relative to a single domain to be managed by its own sandboxed process), the user still has a unique screen, keyboard, brain, pair of eyes and set of fingers. USB keys are a good example of problems: the user thinks of them as "files", not as "files for my Facebook-related tasks". The user will make files from USB keys available system-wide.

Moreover, users really love cross-site behaviours. E.g. they really want blog sites to feature Facebook buttons which do Facebook-related things right on the blog site. Real task separation is a constraint. This is similar to pressure doors in submarines: even when the doors are kept open, you still notice them and you still have to think about them when deciding where objects and men should go.

---

To sum up, having a separate account for system administration is not really needed in modern personal computers. You still need one, not because of any real gain in security (the sysadmin account does not protect that which is important to protect), but because current operating systems are still organized that way, and going against it may break too many things. It is mostly a matter of Tradition, as always.

What you need, if you want to mitigate effects of break-ins, is to apply separation of tasks, which is quite orthogonal to the separation of process that operating systems enforce; indeed, the Web browser is a typical example of a single process which spans several tasks, and this is incarnated by the cookie storage vault, which keeps all your dearest secrets in a single place.

And, of course, internal separation is still mitigation: how to survive breaches while keeping overall losses low. It is better if breaches are not permitted to occur in the first place... which again translates the problem elsewhere. In the submarine analogy, pressure doors are fine, but avoiding enemy torpedoes is finer.

Answer 2

What we're talking here is security boundaries. The boundary between a user physically on a local machine and the SYSTEM context (whichever OS that may be) is there to protect the system. There is also a security boundary between the user on the system and the various applications the user runs, usually by way of the application's own auth mechanism. That boundary is to protect the application and it's data.

These are two totally different boundaries that don't intersect.

Further, the comic (lets be clear, its a web comic) is based on a logical fallacy. If I physically steal someone's laptop I can very likely install a driver without their permission.

Now, the real debate is whether these two security boundaries (and the authn/authz mechanisms that protect them) should really intersect. Meh. The comic itself reminds me of distributed authorization policies, federation, and aspects of PKI. All things we kind of suck at in a controlled environment let alone an uncontrolled environment.

We could do better.

Answer 3

The idea of the Admin account is that it should cover the setup and administration of the system, not the general usage of the computer. This works well for corporate environments, as they don't trust their users.

In home environments most people run as admin with an automatic logon. This is because the inconvenience of setting up accounts is not worth the perceived benefits - most users believe that they know what they are doing, even (or especially) if they suffer from Dunnings-Kruger (http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect).

In an ideal world the OS would sandbox each application and its data. Running software under reduced privileges is a great idea in theory but in practice knowing what privileges to give that software can be complex. Delegating that task to the software installer is a huge security hole.

You will have noticed that Android attempts to implement a solution by advising of the access required by an application on installation.

As for the xkcd, putting a password on the default account and locking the computer when you leave it would solve that problem. Or at least it would if it wasn't fairly easy to reset the admin password (at least on Windows).

Answer 4

What this comic is pointing out is the amusing nature of separating a single duty (i.e. administration) out of the model, but keeping everything that's absolutely critical to your online life accessible from one account. It's not as much a separation of duties as a separation of a duty.

Of course, a lot of this could be solved with single-use high-entropy passwords and a password manager, and disabling "remember me" systems, but again we're running into the territory where a single compromise reveals the entire set of passwords.

However, it certainly does make sense to have a separate root account. UAC on Windows is incredibly useful for damage limitation, in that running as an administrator doesn't actually give administrative privileges to your processes until you explicitly agree to elevate them. This means that you might lose some files if malware gets on your machine, but it can't alter system settings or persist in a strong way.

I think we should move to a more Unix-style security architecture, where individual user accounts are used to host separate services, in order to maintain a better level of control over what they can access. Windows doesn't really allow this currently, but there are some caveats and the OS isn't really designed to use that kind of model, plus local user account creation is rather bloated for that kind of use. Linux, on the other hand, already actively exploits this model to help increase security by separating the privileges needed for each service user.

Answer 5

If the isolation of the administrative permissions is working correctly and the OS prevents snooping from one application to another, then most of the problem described in the comic goes away if you personally follow good security principals. I think the comic is more talking about the fact that the way security is currently approached by the majority of people, the comic is 100% true. This is reinforced by the mouse over text about making sure that it automatically logs in to his brother's account if he's inactive for a period of time.

The number of threat vectors that can attack a system are astounding and some things (like key loggers) could compromise other applications if the OS allows the behavior to be monitored. Thus far, there has been more to gain by letting processes talk to each other than denying it, but that balance may be changing to require a more structured permissions system to prevent things like key loggers from working as easily.

Additionally, if we rule out key-loggers, then the most common thing would simply be that people store their credentials in their browser and so if they are logged in, that is available to the attacker. Simply not storing passwords like that will make a lot of the other issues in the comic go away as well.

The comic does point out that, in part, the security model is less prepared for today's threats than it could be, but it still succeeds at trying to protect the core of the system from compromise. We will just likely have to build more on to that as the threat landscape changes and more control between the interactions of applications is necessary. We in fact already see this on things like Android and iOS where backwards compatibility isn't an issue that needed to be addressed and the need for application interactions is less present.

Answer 6

There is an existing framework that covers all your needs: SELinux. Properly configured, it offers a way to run programs confined into different domains, following the principle of least privilege. Distributions like Fedora install and enable it by default.

In my opinion, a separate admin account is something good (even necessary) to have, and should be used only for administrative tasks.

Being a desktop or a production server does not make a difference security-wise. Both need proper measures being taken.

Answer 7

It's sad if someone manages to steal my laptop while i'm logged in?

Ever heard of Lockscreens and FDE?

EDIT: Passwords belong into containers (e.g. Keepass)

Answer 8

If you think about this from a purely threat vector point of view - somebody stealing somebody else's laptop, logged in (quite common these days in university halls of residence for modifying one's facebook status for the purposes of embarrassing one's friends) then really, the comic doesn't really make a point.

This is because unless you repeatedly insist the user re-authenticate to perform any action, even if you decide to run each browser instance/application in a different virtual machine as per Qubes OS it makes no difference that the applications are isolated from each other because the user is already logged into the "trusted" terminal and can quite happily modify whatever he/she likes.

The only way to really prevent this is to force the user to re-authenticate, which is why screens lock themselves after a certain amount of time, web sessions time out and so on. This stays the same even if you have mandatory access control - assuming of course everything the attacker needs is logged in and loaded up, as the comic implies.

The real, fundamental problem is the lack of re-authentication required to, from a logged in session, open a browser and restart a previous facebook or gmail session. This is the same problem as operating systems have with file access permissions - I can by the same token open an explorer window and delete all of your work.

There is an interesting point in all of this - separating GUI applications from each other such that malware that exploits one of them cannot affect another. My comments on another answer about X11's shortcomings are from this angle. UIPI on Windows is an effort in this direction. Work on Chrome's security model is helping in this direction. Application sandboxes work in this direction. However, none of these solutions are designed to combat a user who already has an authentication token!