To illustrate this, think of entering the place where you live. The lock on your front door both authenticates you and authorizes you to use the house simply by having the key (which is why you don't want to lose it). Computer systems, contrarily, may not allow you to do anything even if you present the appropriate key -- even identifying yourself properly doesn't imply that you're allowed inside. The user database authenticates you, but you're not necessarily authorized to do anything unless the permissions allow you to do so.

There's one exception to this rule in Unix: The root account, for which authorization is assumed. This can be a Unix system's Achilles' heel: While mechanisms to authenticate users can be exceptionally stringent, ranging from smart cards to retinal scanners, the root account is often bereft of such protection. With this structure, if you lose the root password to your system and need access to the files, all you need to do is make the system use a different authentication database, or ignore the database entirely: boot from a CD-ROM, floppy disk, or take the hard drive out and place it in another system. This is like drilling out the lock and replacing it. One way to get access to a "locked" NT system is to boot it from a floppy disk and use the NTFSDOS utility, which allows you to access the drive but completely ignores the NTFS permissions. The same strategy applies to Unix. Therefore, it's extremely important to protect the physical security of your system.

From there, you need to protect your files, and none needs more protection in Unix than the user database. Let's take a look first at how this is done on a Windows NT system, then how you can accomplish it in Unix

Authentication Databases
Windows systems store user, group and password information in the Security Accounts Manager (SAM) database, located at C:\WINNT\system32\config\SAM. It's normally encrypted and inaccessible to anyone but the System account, but some utilities can dump and analyze its contents. Each user is assigned a unique Security Identifier (SID) in this database looking something like the one below:

S-1-5-21-1123561945-920026266-839532115-500

Like hostnames in the Domain Name System (DNS), user and group names are functional for purposes like mail delivery, but also serve as mnemonic aids. When you log in to a Windows system, you obtain credentials identifying you not as your name but as the SID associated with your name. If your SID isn't present in the access control list on a particular file, access to that file is denied. In a Windows NT or Active Directory domain, the database for domain users and groups is stored remotely on the domain controller, although a local SAM database is still maintained for local user accounts, such as the Administrator account.

Unix systems store user and group information in two files, /etc/passwd and /etc/group. These "databases" are simply colon-delimited text files, and can be viewed and edited using a text editor, although most systems provide tools to automate user management.

The /etc/passwd file
Here's a sample password file, with the fields identified above:

Username:Password:user ID:group ID:GECOS:home
directory:login shell
root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:/sbin/noshell
bin:x:2:2::/usr/bin:/sbin/noshell
sys:x:3:3::/:
james:x:20901:1:James Ervin:/home/jervin:/bin/ksh

Let's go through those fields one at a time, starting with the first. Usernames should be unique, but unlike Windows (in which the user creation tools enforce unique usernames and SIDs), Unix doesn't enforce uniqueness. Duplicate names can disrupt the one-to-one mapping between usernames and their numeric equivalents. This can result in strange behavior, so you should avoid them. For historical reasons and maximum compatibility between systems, usernames of eight lowercase characters, or less, are recommended, though longer names may be allowed on some systems.

The password field stores the user's password in encrypted form, often using the DES encryption algorithm. Using brute-force attacks, it's computationally feasible to decrypt or "crack" passwords encrypted using DES within a few days. Windows NT 4.0 systems prior to Service Pack 3 used a weak encryption algorithm and were similarly susceptible. Given this, a determined user can usually gain root access on a Unix system if the encrypted passwords are readable, so extra measures must be taken to protect them. Since the rest of the information in the /etc/passwd file must be readable by everyone for things to work, the encrypted passwords are commonly relocated to another file that only the root account can read, the /etc/shadow file. The x is where the passwords should be, indicating that the system I obtained the above sample from does indeed use "shadowed" passwords. Newer distributions of Red Hat Linux employ the stronger MD5 encryption algorithm, in addition to a shadow password file. Nowadays, authentication duties are often offloaded to another host on the network via an authentication mechanism such as Kerberos or RADIUS. Network authentication reduces the number of encrypted passwords kept on the local system, but the root account generally remains, and consequently, the necessity to protect it does as well.

User ID (UID) values are much simpler than in Windows: Simply begin counting up from zero. 32-bit Unix systems can accommodate up to 2 to the 32nd power UIDs. However, backwards compatibility suffers at more than 65,536 UIDs-2 to the 16th power. The root account always has UID 0. Again unlike Windows, where SID uniqueness is enforced, there's no limit on how many users can have the same UID in Unix - any account with UID 0 has the same powers as the root account, so it's in your interest not to reassign that number. The first dozen or so UIDs are usually reserved for system accounts, as seen in the sample.

Each user can be assigned one ID (GID) value. Like the UID, the GID is a 16 or 32-bit integer, depending on the system. As mentioned in the previous article, most modern Unix systems allow you to be members of multiple groups simultaneously, but only one, the primary group, gets listed in the password file. The root group gets the GID 0.

The GECOS field can be used to store additional information about the user, and used to serve as a sort of phone book entry that could be queried by programs such as "finger." Since "finger" and other programs that reveal information about users are now regarded as security risks, the GECOS field is largely irrelevant, as its functions have been replaced by LDAP-based directory services and other alternatives.

The home directory is the home directory of the user. This directory ought to exist, but its absence may not prevent a login on some systems. Of course, the permissions on the user's home directory should be set so that the user can read and write files there -- otherwise it's not much of a home.

The login shell is the name of a program that gets run when the associated user logs in. Normally these are the interactive shell programs, the Unix equivalents of the Windows cmd.exe program: /bin/sh, /bin/ksh, /bin/bash, and others. A login shell can be anything, though. If a program used as a login shell is removed or replaced, you might be prevented from logging in. A common hacker trick is to replace one of the default shells with something better suited to their purposes -- a keystroke logger, for instance. Since all users that log in run these programs, protecting these programs is of extreme importance, second only to protecting the password file itself. It's also important to know who is logging in to the system, and to ensure that any users you don't want to actually log in interactively are unable to do so. One method of accomplishing this is to assign a false login shell in the password file (remember, the login shell can be any program). In the above example, several of the system users have had their login shell replaced by "/sbin/noshell." This is a small, freely available C program that simply denies the logon, and logs the attempt to the system log.

The /etc/group file
The /etc/group file is much simpler than the /etc/passwd file, and should be self-explanatory after the foregoing. Here's the beginning of a group file:

Group name:password:Group ID (GID):Members
root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
(more entries follow…)

The password field is hardly ever used and can be left blank on most systems. Commas with no spaces separate group members in the fourth field.

The Masquerade
Unix allows you to assume another user's identity via the "su" or "substitute identity" command. A Windows 2000 equivalent is the "runas" command, which permits you to run a command or application as another user. Various versions of "su" have been implemented on older versions of Windows NT that lack the "runas" capability. Here's a sample session in which I use "su" to become the Oracle user.

James@nostromo /home/James $
/bin/su - oracle
Password: xxxxxxxx
$

Notice that I specified the full path to the "su" command to run it, "/bin/su." It's good practice to specify the full path to any especially powerful program. By doing so, you reduce the risk of running a different copy of the command placed somewhere else by a disgruntled user. Here, the "su" command prompts me for the password of the other user, but the root account can impersonate anyone without being prompted. This, of course, leads to frequent abuse: The tendency is to use the root account as an alternative to remembering passwords. This constitutes bad practice, unless only the root account is allowed to use "su," as is the case on some systems.

Introducing the "su" command raises the question of why we might want this capability. The answer lies in the concept of the user environment, a group of settings pertaining to each individual user. Each user can customize their environment to their liking. In the above example as the user "James," I prefer to know who I am, what machine I'm on, and where I am in the directory structure, so I've configured my command prompt to show those things. After becoming the oracle user, though, I get the default dollar sign ($) prompt, because I've been too lazy to configure it otherwise. Using the "env" command, though, I can see that I've configured a great many other things in the oracle user's environment. The output of the "env," or "environment" command is a list of my environment variables:

$ env
TMPDIR=/var/tmp
PATH=:/export/oracle/app/oracle/product/8.0.6/bin:
/usr/bin:/usr/local/bin:.
ORACLE_BASE=/export/oracle
LOGNAME=oracle
ORACLE_SID=ORDB
SHELL=/bin/ksh
ORACLE_TERM=vt100
HOME=/export/home/oracle
LD_LIBRARY_PATH=:/export/oracle/app/oracle/
product/8.0.6/lib
TERM=vt100
ORACLE_HOME=/export/oracle/app/oracle/product/8.0.6
PWD=/home/oracle
TZ=US/Eastern

Clearly, I don't want to retype all that. The "su" command allows me to quickly replicate the exact circumstances of another user. In addition to perpetuating my laziness, this is an invaluable diagnostic capability, should a user report a problem that I can't replicate using my account. Another common use of "su" is to start a process as a less privileged user. For instance, a user with very minimal privileges should start a Web server process, since it will be accessed anonymously.

There's one instance that the "su" command doesn't account for: When it's necessary for less privileged users to start processes as the root user, but inconvenient or unwise to dole out the root password. For this purpose, there's a freely available tool called "sudo" which operates similarly to "su" but has additional logging capabilities and granular control over which commands are permissible. For instance, you might allow a departmental secretary to perform password resets by allowing him to use the "passwd" command via "sudo." In general, though, any use of "sudo" is a substantial security risk and should be closely evaluated.

Next time, we'll explain those environmental settings a bit, and learn a few ways to mangle them besides.

Comments? Questions? Post your thoughts below!