I have recently been discussing with an employee of a company based in Cupertino the difference between "root," "super user," and "administrator" users both in general, and as they apply to MacOS X, and also to Unix. It's important to note that all three are separate. General would include the administrative users on a local Windows machine, as well as an administrator in Active Directory, in addition to the Administrator on a MacOS X box. They're all different of course. But what's been bothering me is the sort of sleight-of-hand Apple is pulling with its documentation. To whit,(via) and also:Administrative Accounts
Although the root account is disabled, Mac OS X establishes an admin user account when the system is first installed. The admin user can perform most of the operations normally associated with the root user. The only thing the admin user is prevented from doing is directly adding, modifying, or deleting files in the system domain. However, an administrator can use the Installer or Software Update applications for this purpose.
Any user on the system may have administrative privileges, that is, there is no special need for an account with the name
admin. Admin users gain their privileges by being added to theadmingroup; non-administrative users belong to thestaffgroup. An admin user can grant administrative rights to other users of the system using the Accounts pane of System Preferences
Resetting an Administrator Password
Using the Mac OS X Server installation disc, you can change the password of a user account that has administrator privileges, including the System Administrator (root or superuser) account.
(via) again.
But, as anyone can see:
The progression here is as you would see on any stock, standard installation (note: I have installed the dev kit, but I doubt that bothers /etc/sudoers). When I open a new terminal, I am the alex user. We see the % prompt, which is standard for zsh non-super-users. I issue the command sudo su -, which essentially says, "make me uid 0 (zero), and run through that user's login process [e.g., run their .profile]." We see that the machine does as I ask after I issue alex's password, not root's. This is verified by the root# prompt, where the octothorpe (#) is the standard Unix convention for "you're root, please don't fuck things up."
The next command is a little more (or less, depending on your familiarity with sudo(1) [hm, section 1 of the manual is for binaries, which is where sudo should be, but it's been stuffed into section 8, which is for miscellaneous stuff. So here, I've said (1), but it's really in (8). Behold: No entry for sudo in section 1 of the manual] ) subtle. Instead of asking sudo to become root, we ask sudo to give us a shell. Now, we see again the octothorpe, but we don't see the prompt from before, gordon:~ root# . This is because we did not run through root's login process. Root, on Darwin, is given the shell /bin/sh. This shell, which is actually bash hiding in disguise,
gordon:~ root# cksum /bin/{,ba}sh
1901100275 1068844 /bin/sh
1901100275 1068844 /bin/bash
gordon:~ root# ls -la /bin/{,ba}sh
-rwxr-xr-x 1 root wheel 1068844 Dec 13 2006 /bin/bash
-r-xr-xr-x 1 root wheel 1068844 Dec 13 2006 /bin/sh
is different from alex's shell (zsh) [hi, nate], as we can see from niutil (ordinarily, we'd use /etc/passwd, of course, but OSX has this fancy netinfo garbage that hides things like that from us):
gordon% niutil -read . /users/alex | grep shell
shell: /bin/zsh
So anyways, what we've shown is that an ordinary "Administrator" (in Apple parlance) can become the super-user quite readily. Apple's documentation states that the simple Administrator is able to change parameters on the machine (and shut it down, eject/unmount devices, and so on), but cannot, for example, see files in other users' home directories. This is not the case. At all. It's misleading at best and devious at worst to suggest that having a differentiation between uid 0 ('proper' root) and a user who is enabled in sudoers with the keys to the kingdom:
gordon% idThat ALL keyword being of course key. Administrator users are put into /etc/sudoers with the rights to do anything they please on the machine. This means the literature, as I said, is wrong, misleading, and probably intentionally so (as Apple has kind of struggled to keep a toehold in the DoD space, which has certain strictures). As I teach a class on the STIG, I can kind of understand why they would make this fallacious logical distinction between uid 0 and "regular Administrator users," but of course, as an instructor I find it reprehensible that they blur the line so, and I have to help somebody who works with Macs understand this. Mainly by this giant rant. But that's beside the point.
uid=502(alex) gid=502(alex) groups=502(alex), 81(appserveradm), 79(appserverusr), 80(admin)
gordon% for group in `groups`; do sudo grep $group /etc/sudoers ; done
%admin ALL=(ALL) ALL
Since I want to distinguish here between Apple's terminology and Unix terminology, let's continue a little here.
In Unix, we have non-zero users, and we have root. Technically, there can be more than one user with uid of zero, but this is generally frowned upon (the Seebass/Nemeth/et al book being just one to warn against this). Users with an id of zero are allowed to rape, pillage, raze, ransack, and even mount volumes on Unix machines. This is sort of the achilles heel in Unix security, and one thing that Microsoft (and recently, even Sun) have rightly attacked. We can give non-root users the ability to execute programs (typical examples being ping(1) and traceroute(1)) as root, by creating "set uid" variables. These programs, when they launch, they become the uid of whichever they're set to, including 0. They are of course security risks, and frowned upon, because as I have said, once you've become root on Unix, it's game over. That user can do anything. This is changing of late, and Unixes are starting to get ackles and arbacks and things like this. The good news is it's generally pretty hard to become root, but the rule of thumb is, once they get onto the machine, they can pretty much become root through surreptitious means with impunity. The goal is to keep them off the machine entirely.
Windows is a little different, and this is largely owed to its torrid tryst with DEC VMS. Windows also has two kinds of local users, administrators and regular users. There's finer granularity than there is with Unix (or, for that matter, MacOS X), with the ability to restrict the administrative privileges of some users to specific things (I don't have an exhaustive list; finding one would be fruitless as it changes per release). The notion, though, is that with a big, mean operating system like VMS, designed to run on gazillion-dollar, building-filling VAX machines, you want to have Joe from one department able to remove tapes (and I mean tape, like big round spools, not DDS3 or LTO) or connect/disconnect devices, but heavens to Betsy, don't let him turn the machine off, the whole company would fall over. And so on. It's worth noting that sudo kind of replicates this granularity (but of course, sudo itself has been compromised more than once, and is itself a risk).
Users can sometimes be everywhere at once, or get from one place to another with little difficulty.The next level of user resides in a network directory. Well, usually it's on a network. It can be built on a local machine. Examples of this are LDAP and Active Directory, Kerberos, NIS and NIS+, and of course NetInfo on the Mac/NeXT machines (which is a level of abstraction Apple could be whoring up, but doesn't, I suspect, for fear of scaring sysadmins like me. I really want to be able to grep myself out of /etc/passwd, and can't with NetInfo. Or maybe they've realized that NetInfo kind of sucks and they're going to replace it with LDAP or something else sensible....). Anyways, the notion here is that I tell my machine here, let's say my laptop, that when it gets a request to authenticate, say from me, that it's going to take the tokens I gave it ("alex" and "PAssw0RD"), and hand them to some server somewhere else that tells it (the laptop) whether it's okay to permit me access to the machine, and what sort of permissions to give me (and where my home directory lives and other various and sundry things like this).
So we have this sort of "network-level" administrator, as well as the local administrator. In some of these systems, after we've told our machines they have a network directory of users, they disallow local logins, including the ever ebullient Macintosh. If you join a Mac to Active Directory, only an administrator in AD can actually un-join it because it is (properly) refusing to allow somebody to circumvent the permissions in the network directory (although this, too, is get-around-able).
Network directories are applicable to every kind of operating system I've ever worked with, and have evolved from the days of Cutler and Knuth and all those old farts to the current, sexier, more complicated, but still vulnerable systems. Basically, the new ones have GUIs, and the old ones didn't.
But none of this forgives Apple. Apple has distinguished between a super-user and a super-user by a trick of vocabulary, and it unnecessarily confuses their users and ostensibly their employees. It isn't hard to say "users on the box with admin privileges are root, they own it, etc", but it kind of makes it sound dire to give a user Admin privileges. I'll finish this somewhat longish rant on privileges with an anecdote.I was teaching a course in Virginia Beach when a Navy sysadmin of twenty years kind of raised his hand and suggested to me as I was giving roughly the above lecture, "You know, you paint kind of a dire picture. Is it really that bad?"
Yes. It's that bad. Your box is probably owned. You probably did it. And if it isn't, it will be. And, it will be because you didn't understand your own permissions model, probably because your software vendors have so confused the issues you can't understand how to securely and safely administer your machine.
