Single-user Unix

There are a few basic security rules that every Unix newbie is taught, and one of them is: don't log in as root. So when I went to demonstrate something to a new coworker a while ago, and began by logging in as root, it was an awkward moment.

Was I being reckless? No, I was using Unix as a single-user OS. This was a shared machine, used for testing and little else, and there was no reason to distinguish multiple users; everyone needed root access anyway. Having multiple accounts would have been useless complexity; all we needed was a single-user system. Unix can be one, if you log in as root.

It's not a very good single-user OS, because most of its safety checks are user-based. When everything runs as root, a minor accident can destroy everything on the machine. But this machine had no valuable data on it — at worst, we'd be forced to reinstall everything, so we didn't even bother to use a shared non-root account. Safety just wasn't much of an issue. Security wasn't an issue at all; everyone who used that machine needed to know the root password anyway.

This isn't an unusual situation. Most personal computers have only a single user, and many others are shared among several users with no personal data. The user-based security model was developed for timeshared machines, which are now quite rare. Yet our orthodoxy still says user-based security is necessary, and systems without it are not to be taken seriously. Even after decades in which the most important computers have been personal ones, and even now that single-user smartphones have become the most fashionable platforms, we still judge operating systems by their ability to protect multiple users from each other, not their ability to protect a single user from malicious code. Security, we think, means inter-user security, whether or not that's a good model of the threats we face.

So I feel guilty every time I log in as root. I've been indoctrinated too thoroughly; even though I know it's not really a problem, I feel compelled to make excuses, and to point out that it wasn't me who set up that machine, and I wouldn't have done it that way. But I shouldn't. A single-user system is not necessarily a bad thing, even if it's Unix.

3 comments:

  1. Users aren't just used for timesharing - they're also used to assign identities (and thus implicitly a set of capabilities) to executing code. With the decrease of timesharing, this is in fact their dominant usage model.

    With an increasingly internetworked world, with code coming from disparate places and thus is trusted less, I would argue that the need for assigning identity to, and limiting capabilities of, executing code is more important now than ever.

    Of course, users as a security model - ACL-oriented, with every object marked up by what identities can do things with it - is probably worse than the alternatives, like capability based security, where code is powerless (and thus secure) by default, but has capabilities granted to it explicitly, perhaps mediated by secure UI, and only by following the transitive object graph can it gain access to more capabilities. In this model, functions and properties become firewalls to granting new capabilities.

    ReplyDelete
  2. And it still makes sense to have two users, self and root, so that you aren't root unless you ask to be (sudo is a win here most of the time).

    ReplyDelete
  3. There actually was a non-root account on that machine, but the source tree belonged to root, and changing that would have annoyed the person who set it up, so it was necessary to be root most of the time.

    (Yes, we ran compilers as root.)

    ReplyDelete

It's OK to comment on old posts.