|
|
|
|
|
|
|
|
Mr. Bandel tells us all about users/groups, UIDs/GIDs, permissions and security. In short, how to successfully manage your users. by David Bandel
Once your system is installed and most of the services configured, it's time to add users. You may not have given this task much thought yet, but you should.
If you're like many Linux beginners, you may not understand the implications of giving someone access to your system. Perhaps, for some time, you've been using a Unix variant, in which the basic decisions have been handled for you. Indeed, some installation programs, such as Caldera's LISA (Linux Installation and System Administration), start the process for you by adding a user during the install process and then allow you to continue using it to add and delete users from the system. So what else is there to know?
For starters, adding users entails thinking about how you wish to administer the system overall. Security is directly affected by such things as groups and passwords. Their administration shouldn't be left to chance or the whims of the installation program--at least, not without exploring their impact.
When you add a user, however you do it (I'll mention some programs later), you add an entry to the /etc/passwd file. This file consists of seven colon-separated fields, specified all on one line:
col:JkH7XmXwH6e/E:100:100:Bandel:/home/col:/bin/bashThe fields are: user login name, password, UID, GID, comment (gecos) field, user's home directory and user's default shell.
If you decide to edit the /etc/passwd file manually, please be sure to make a backup copy first, so that if something goes wrong, you can start over. In general, I recommend using one of the programs specifically designed to edit the /etc/passwd file.
The first field is fairly self-explanatory. The system matches this entry with the next field as the user's login name/password pair. Each name must be unique. This is the only field required to be unique; I will explain the implications of keeping certain other fields unique below. Beyond that, making the user name meaningful helps to quickly identify who sent a 10MB file to the printer when the boss needs a hard copy of his budget for a Board of Directors meeting in ten minutes. In most Unix variants, including Linux, the login name is limited to 8 characters.
The second field is the password. This field can contain any of a number of things, but normally contains an encrypted password. The encrypted password must be 13 characters in length, composed of a two character seed plus the encrypted password. Other entries often seen in the password field include: ``*'',``LOCKED'' and ``VOID''. If you see an ``x'' in this field, you'll want to read about shadow files below. These, or any other incorrect entries, effectively lock this user out. If you wish to lock a user out without losing the password they are using, you can insert an apostrophe as the first character. An apostrophe can never be used as part of the "scrambled eggs", so apart from being illegal as part of a seed, you have also made the field size 14 characters. To allow the user access, just remove the apostrophe.
Also note that this field might be empty. Always check the /etc/passwd file to ensure that the second field is not empty. A field is defined as empty or NULL if the two colons delineating this field are next to each other with nothing in between, not even a space. If it is empty, no password is required to log in. The implications of this are obvious.
The third field is the UID (user identification). Valid UID ranges are from 0 to 65534. A UID of 0 has a special significance to the system; it is the omnipotent ``superuser'', a term derived from the su (substitute user) program normally used by a normal user to become root. When invoked without an argument (user name) or with only a hyphen (-), root is the default.
A UID of 65534 is commonly reserved for ``nobody'', a user with no privileges as opposed to a non-privileged user. This UID is often used for individuals accessing your system via FTP or HTTP.
Custom dictates that the numbers 1 to 99 are reserved for system users, such as wheel, daemon, lp, operator, news, mail, etc. These numbers are more than sufficient for most system requirements. Also, you may want to reserve 100 to 999 for semi-privileged (for lack of a better term) users. These users are administrators who don't need total root powers, but who do some administration and thus need more privileges than those given to non-privileged users. Reserve 1000 to 9999 for local users and 10000 to 65534 for remote users (if any).
Reserving groups of numbers for particular users helps if you ever need to search through logs for suspicious user activity. Some distributions, like Caldera, start UIDs at 100, others, like Red Hat, at 500, and still others, like Debian, at 1000 for non-privileged users. Just decide on a scheme and stick to it. Since each distribution does its own thing, in order to mix distributions within an organization, you have to intervene manually if the systems are networked. This is particularly true if you want to use NIS or NFS to mount common directories (e.g., /var/spool/mail, /home).
Contrary to popular belief, the UID field does not have to be unique. In fact, one method that keeps ``wanna-be'' system crackers busy is to use the technique discussed above and put an apostrophe as the first character in the password field for root. Then create another entry, perhaps tuber, with a UID of 0. Some systems require the root entry to exist and be the first entry.
But beware: a non-unique field can cause problems. For example, if you are logged in as tuber (UID 0) and activate a password-protected screen lock, when you attempt to unlock it, you will find you've outsmarted yourself. The kernel knows you by your UID; it looks up UID 0 beginning with the top of the /etc/passwd file and finds it as the first entry corresponding to ``root''--that's where it stops; it doesn't look any further. But root's password has been locked with an invalid entry. At this point, your choices are to telnet in and kill the screen-lock process or to reboot the machine. The other possibility for getting out is to use an unlocked virtual terminal if you have one running to which you can switch. (Sometimes, the ``extra'' virtual terminals come in handy.)
Before I leave UIDs, here are two more things to think about. First, if you have any ``rhosts'' files with references to other systems outside your own network, make sure your user names are unique not only in your system, but between systems. If you have a jonesd (for Donna Jones) and the other system has a jonesd (for Danny Jones), and they use rlogin to remotely log in to each other's systems, they'll have access to each other's files (as the other person). These files can cause many problems and probably should not be used.
The second thing is the find command, which is used extensively by systems-administration programs and can be used to find user's files for deletion or changing owners (chown) before (or after) the files become orphaned. Learn this command, and incorporate it into your tool box. See the side bar ``A Few Words About the Find Command''.
A Few Words about the Find Command
The fourth field is the primary GID (group identification) number. Every user belongs to a group. Some distributions use a common group such as ``users'' to which everyone belongs. Others create ``private groups'' and assign each user to his own private group as their primary or default group. Caldera uses a common group, while Red Hat and Debian use private groups. I would recommend reading the Red Hat Users Manual, available via anonymous FTP from ftp.redhat.com/pub/redhat/redhat-4.1/Users-Guide/ in various formats. A discussion of private groups as they relate to easing the system administration burden can be found in this manual.
To discover the groups they belong to, users can type groups at the command prompt. The first group name returned is the default group. Files saved by that user will, by default, have the group identifier set to the first value returned unless the subdirectory has the ``setgid'' bit turned on.
The fifth field is a comment, which usually contains the user's full name. You may see this field referred to as a gecos (General Electric Comprehensive Operating System) field. Shadow files sometimes use this field for something other than a user's name, but only under special circumstances.
The sixth field is the user's home directory. The cd command given with no argument or with the tilde (~) as an argument will move the user to this directory. This directory must have a full path name, i.e., start at the root and go down. One notable exception to this rule is the system user ``bin'', which has a relative path of bin as the home directory, because several bin directories exist on the system.
The last field is the user's default shell. Most Linux distributions (in fact, all of those I am aware of) default to bash, the Bourne Again Shell. For most users, this is probably the best overall shell. C programmers tend to like the syntax of one of the C shells (csh or tcsh), but for writing scripts, most users will do better with bash. If you need a user to have a system entry for any purpose (perhaps a WWW database account), but don't want him to be able to log in, you can specify /bin/false as his shell (as is usually done with the nobody account). The shell can also be a program that runs when the user logs in, but it would be the only thing the user could do--exiting the program would log him out. If you choose this option, be aware that some programs allow users to start a shell from within the program. If the program ``shells out'' to a true shell, then the user has a back door into the system.
A complete discussion of shadow files is beyond the scope of this article. However, just to give you some idea of what they are and why they were created, I offer the following. The /etc/passwd file is ``world'' readable; anyone can make a copy of it. ``So what,'' you say, ``the passwords are encrypted and can't be used.'' Not true. Most users, in particular those who choose their own passwords, choose passwords that can be guessed or broken by a ``dictionary attack'' --that is, by using a program such as cops, an attacker can run a dictionary through crypt using the seed from the password to see if they get a match.
When the shadow file is used to maintain passwords, it is not world readable and cannot be copied off the system. An ``x'' in the password field tells you that this system uses shadow passwords. The shadow file also contains information about when the password was last changed, if the user will be forced to change it and how often (password expiration date), etc. Periodic forced password changes reduce risks posed by users who do not guard their passwords well.
Most recent Linux distributions include the PAM (pluggable authentication modules) libraries. PAM doesn't require applications to be ``PAM aware'' in order to function correctly, but these are only libraries and do require programs written with them. The shadow suite requires numerous programs to be recompiled or replaced with shadow-aware applications. If you need this kind of security, you need to do some serious reading.
The /etc/group file is also a colon-separated list consisting of only four fields: group name, group password, GID and members. The group name/password pair works the same as the /etc/passwd file. However, groups usually don't have passwords associated with them. A quick look at your /etc/group file will reveal the second field doesn't have an entry. Adding passwords to groups doesn't normally enhance security, since users are even more lax about group passwords (why not, everyone knows it) than their own.
The original group implementation in Unix allowed a user to belong to only one group at a time, and they changed group if required. Now, belonging to several groups at a time is common, so this has little relevance in most situations. Files are saved as the users' primary group, but can be changed manually using the chgrp command or via the setgid bit on the directory. The third field is the group-identification number and is functionally equivalent to its /etc/passwd UID counterpart. The fourth field consists of a comma separated list of group members (no spaces are used following the comma).
One last note on the /etc/passwd and /etc/group files. Several distributions I've worked with lately have been adding a line to the bottom of the file like this: +:::::: (The /etc/group file will only have four colons.) This line is added so that NIS databases are appended if no matching entries are found for user/password pair. This must be the last line in the file. Entries following this line are not read. I highly recommend that if you are not using NIS, you delete this line and use chmod to change permissions on ypbind so that it is not executable. If you run ypbind without a properly set up NIS server and the proper databases, you are vulnerable to someone who can trick your machine into binding to his server and reading his NIS maps to gain unauthorized access to your system.
All of the Linux distributions come with facilities for automating the process of adding, modifying and removing users. All include shell scripts or programs such as adduser, useradd, usermod and userdel. Some distributions, notably Caldera and Red Hat, come with additional programs to do the job. Caldera uses its LISA program to handle adding and deleting users. Red Hat's usercfg, for use in a graphical (X11) environment, not only handles user additions and deletions, but also helps manage groups.
All accomplish certain basic chores beyond just adding a line to the /etc/passwd file and appropriate entries to the /etc/group file. Given the sensitivity of the /etc/passwd file and the consequences of corrupting this file, that alone would warrant its use. A system no one (not even root) can log into isn't much use. In fact, if you do edit /etc/passwd with an editor, you shouldn't keep it open long. This file is accessed by numerous programs for login and authentication purposes, and holding this file open (especially if another user decides to change his password) could cause system instability.
All these scripts and programs prompt you through the information needed to create the new account. If you need to add or delete group accounts, the groupadd and groupdel (delgroup, addgroup, groupmod, etc.) programs can be found on most systems to accomplish this task.
The use of Network Information Services (NIS), formerly known as the Yellow Pages (a trademark of British Telecom) and still carrying the ``yp'' prefix on the programs, will necessarily change some of the procedures I've discussed, but the basics remain the same. NIS is used at larger sites to ease the administrative burden of pushing changes to each machine. But accounts still need to be set up. NIS just centralizes and distributes files from the master server instead of changing files on each machine individually. If you do work at a large site that uses NIS, you'll still have some normal accounts set up on each machine for those times when maintenance requirements dictate bringing the machine up in single user or non-networked modes.
Since I've been mentioning security from the beginning of this article, I thought I would mention a few programs to help you maintain security on your system.
The first program, npasswd (no relation to the file created by reversing the shadow password conversion), does some sanity checking when users change their password. This program is used in place of the regular passwd program by renaming the passwd binary (/usr/bin/passwd not /etc/passwd) to something like passwd.orig and creating a link to npasswd from passwd.
Another program you may be interested in is pwgen. This program generates random passwords containing mixed upper and lower case characters, numbers and legal (for a password) punctuation. Personally, I find these passwords too difficult to remember, and since writing them down is a security no-no, I devise my own (hopefully) secure passwords.
I mention the pwdutils package only for those using NIS. This package contains NIS compatible programs. Those contemplating using NIS or shadow files need to ensure that the programs they use for system administration (particularly user administration) work with NIS or the shadow suite. Above all, before you begin installing either NIS or the shadow suite, RTFM--read the fine manual (and keep an emergency boot disk handy).
Among the myriad things you can do that will make your life easier as a systems administrator is to maintain certain files and subdirectories. One such subdirectory that is often overlooked is /etc/skel. This subdirectory is the skeleton used by all (that I'm aware of) scripts and programs to create the new user's $HOME directory. You've seen how administration programs add users to /etc/passwd. You've noticed that at the same time a /home/$USER subdirectory is created with proper permissions and a few common files, such as .bashrc, .cshrc, etc. All this is done by copying /etc/skel with all its files and subdirectories to the user's new home directory and changing the ownership (chown) to the new user. Use the /etc/skel directory to keep all the files you wish new users to have--maybe a default .fvwmrc for their X sessions or some changes to their .bashrc files. Then the new user will be ready to start working as soon as you've run the adduser program.
If you view some of the programs I've discussed, you'll note some are binaries and some are scripts. I prefer to use a modified adduser script in which I have included a couple of lines for something I occasionally forget. My Caldera boxes run a modified fvwm (from LST) that writes to the file /var/run/xlaunch/$USER/background-:0.0. While not a fatal error if the directory doesn't exist, I don't like to see error messages scrolling through my console box. So, my modified script includes two lines to create this subdirectory and then touch the file name. You can modify your scripts in a similar manner.
Once set up, user administration is not that difficult. The necessary tools are installed by default, and some nice GUI programs make the task almost enjoyable. A well-thought out user-administration policy will help you enhance security while making the system friendlier and easier to use for both you and the users. Create some accounts and introduce your friends to the joys of ``Linuxing''.
David Bandel is a Computer Network Consultant specializing in Linux, but he begrudgingly works with Windows and those ``real'' Unix boxes like DEC 5000s and Suns. When he's not working, he can be found hacking his own system or enjoying the view of Seattle from 2,500 feet up in an airplane. He welcomes your comments, criticisms, witticisms and will be happy to further obfuscate the issue. He can be reached via e-mail at dbandel@ix.netcom.com.