Introduction to Users and Groups
| The users and permissions model that FreeBSD and most UNIXes use is fairly simple and single-layered. There are only two types of users: regular users and the super-user, or "root." Regular users are subject to user permissions that restrict what they can do; only the super-user is free of these restrictions. Other permissions models (such as that of Windows 2000/XP) involve more complex layering, which is intended to facilitate certain system functions, such as authentication services and system-level processes. The simpler model of FreeBSD requires you to do a few more gymnastics when it comes to tasks such as setting up a web server with proper permissions to protect it from unauthorized access by shell users (covered in Chapter 26, "Configuring a Web Server"). However, the alternativea more complex permissions systemmore than likely means a less secure system, because there's so much more that can go wrong. Note A more complex permissions modelAccess Control Lists, or ACLsis available in FreeBSD if you choose to use it; it's discussed later in this chapter. ACLs let you designate certain resources as being accessible by a specified list of users, rather than making you use groups and permissions masks. Every regular user on a FreeBSD system has limited permissions and a place to dwell (a home directory). When you connect to the FreeBSD machine remotely, it's generally as a regular user rather than root, and you're placed into your home directory where you're surrounded by files that you can modify only because you own them. To gain elevated status, you need to promote yourself to the super-user using the su command (or the preferred (su -, which simulates a full root login complete with environment variables). This prompts you for the root password, which is the "key to the kingdom" and the most important piece of information you'll have to remember in maintaining your system. After you gain root access, you have as much freedom to createor destroyanything on the computer as you would on a single-user Windows machine. Caution Any time you are logged in as root, you should cultivate a heightened sense of security consciousness, a wariness that someone malicious could be eavesdropping to get the kind of access that you have. The root password should never be transmitted over the network in clear-text, and it should be changed every few months as a rule (see Chapter 30 for more details). You cannot be too careful with this vital piece of information. In order to execute the su command, you need to be a member of an elite group called "wheel." Although FreeBSD has only regular users and the super-user, the wheel group effectively creates a special class of regular usersthose who are allowed to become root (using su). You can use su and this special class to delegate administrative responsibility to others that you trust. Note FreeBSD differs slightly from most distributions of Linux and many other UNIX-based operating systems in that it does not allow you to connect directly to the system (via Telnet or SSH) as root. This is a security measure. To gain root access, you must connect as a regular userspecifically, a user who is a member of the wheel groupand use the su command to promote yourself to super-user status. This means that the root password alone will not give anyone access to your system; that access also requires a user's password who is in the wheel group. A determined hacker will find ways to discover both of these passwords, but the added step is a significant deterrent. If you really, really must turn off this feature and make FreeBSD allow direct root access, you can do so by editing the file /etc/ttys and adding the keyword secure in the field to the right of network in the first few entries in the Pseudo terminals section: ttyp0 none network secure ttyp1 none network secure ttyp2 none network secure This is, however, considered an extremely risky maneuver, and not one you should use if you can possibly stand simply logging in as yourself and using su. Another kind of distinction among regular users is between actual login users (people who connect to the system) and automated users (such as bin, operator, daemon, nobody, and others). These user accounts exist in order to "own" certain system processes and server applications. It is important to realize that processes, just like files, are each owned by some user, and all processes are bound by their users' permissions when interacting with files and other processes. This ensures that system processes that create files do so under the limited permissions of their owner users, rather than as root (which can be dangerous and insecure). Users never really access their files directly. Everything a user does to his files by giving commands is effectively done by executing processes running with the user's assigned permissions. Those processes then operate on files and other processes, as illustrated in Figure 13.1. The processes owned by user1 can only operate on the files and processes owned by user1; permission would be denied if any of those processes tried to change any of user2's files or processes in any way. In the simplest setup, each user can change only those files and processes that he owns. Figure 13.1. A user executes processes, which then operate on files and other processes. Imagine what would happen if user1 were the super-user. That user's processes would have absolute power over any other user's files and processes. If one of user1's processes is, for instance, a program that reads a configuration file and then modifies items in the system specified in that file, suppose an unauthorized user managed to modify the configuration file in a malicious way. user1's program would be then vulnerable to any such misconfiguration, and depending on its capabilities, could completely ruin the system. This is why most system processes, except those that are absolutely trusted, run under the ownership of one of the automated pseudo-users instead of running as root. |
