keep its users secure. If you haven't installed the software discussed by the advisory, you don't have to worry.

Both types of security advisories generally contain a description of the problem, fixes, and workarounds. Read advisories carefully, since you can be sure that some script kiddie is looking for a vulnerable machine to break into. The best thing to do is to be invulnerable to these problems.

Note We will discuss many security tools in this chapter. While none is sufficient, all are desirable. Treat everything you learn about in this chapter as a tool in a kit, not as the answer to all of your problems. For example, while simply raising the securelevel will not make your system secure, it can help when combined with reasonable permissions, file flags, patching your systems, password control, and all the other things that make up a good security policy.

Installation Security Profiles

When you first install FreeBSD (version 4.2 or later), you have the option to set a security profile, which basically enables and disables network services and sets the default system security according to some common defaults provided by the FreeBSD Project. (Everything the security profile changes is set in /etc/rc.conf.) In most cases, you should use these profiles as a starting point and edit the configuration set by the profile to meet your needs. The following sections give a rough description of the two security profiles: moderate and extreme.

Moderate

The moderate security profile enables inetd, sendmail, and sshd. This way, the system can send and receive email and allow people to connect remotely via ssh. Also, if you've previously configured the system to use NFS, portmap will be running so that the system can provide NFS services. The securelevel remains at the default of −1.

Extreme

With the extreme security profile, no basic system network daemons are running, except for extra software you specifically install, and the system securelevel is set to 2. The system will not receive or send email out of the box, and you cannot connect to it remotely. It's unhackable, because it's sitting there with nothing coming in or out.

While security profiles provide useful templates, you need to know how to configure each of these services yourself. Take a look at rc.conf (explained in Chapter 9) to learn how.

Root, Groups, and Permissions

UNIX security has been considered somewhat coarse because one superuser, root, can do anything. Other users are lowly peons who endure the shackles root places upon them. While there is some truth to this, a decent administrator can combine groups and permissions to handle almost any security issue in a secure manner.

141

The root Password

Some actions require absolute control of the system, including manipulating core system files such as the kernel, device drivers, and authentication systems. The root account is designed to perform these actions.

To use the root password, you can either log in as root at an actual login prompt or, if you are a member of the group wheel, use the switch user command su(1). (We'll discuss groups in the next section.) I recommend su; it logs who uses it, and it can be used on a remote system. The command is very simple to use:

..........................................................................................

# su

Password:

#

Next, check your current username with the id(1) command:

..........................................................................................

# id

uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest)

#

..........................................................................................

You now own the system—and I do mean own it. Consider every keystroke very carefully; carelessness can return your hard drive to the unformatted empty metal it shipped with. And use the root password sparingly, because anyone who has the root password can inflict unlimited damage upon the system. Do not give it to anyone who does not strictly need it!

This naturally leads to the question "Who needs root access?" Much of the configuration discussed in Absolute BSD requires the use of the root password. Once you have the system running the way you like it, however, you can greatly decrease or discontinue the use of the root password. One of the simplest ways to do this is with the proper use of groups.

Groups of Users

UNIX classifies users into groups, each group consisting of people who perform similar administrative functions. You can have a group called "www", which includes the people who edit Web pages, and a group called "email", which includes the people who manage your mail server. You can set files and directories to be accessible to specific groups. Most group information is defined in the file /etc/group.

Each line in the group file contains four colon−delimited fields. The first is the group name. Group names are fairly arbitrary: You could call a certain group of users "xyzzy" if you wished. It's a good idea, however, to choose group names that give you some idea of what they're for; while you might remember that the group xyzzy manages your email system today, will you remember it six months from now? Choose group names that mean something.

142

The second field contains the group's encrypted password. Group passwords encouraged poor security practices, so most modern UNIXes don't support them. However, some old software expects to find a password field in /etc/groups, so rather than leave this field blank or remove it entirely, use an asterisk (*) as a placeholder.

The third field holds the group's unique numeric ID (GID). Many of FreeBSD's internal programs use this GID, rather than names, to identify groups.

Last is a list of all the users in that group. To add a user to a group, simply add the username to this list, separated from other names with commas.

After editing /etc/group, it's a good idea to make sure you haven't made a mistake. To double−check your work, use chkgrp(8). It will double−check your work for you; if it runs silently, you haven't shot yourself in the foot.

Primary Group

The group file does not contain a complete list of all users in every group. When you create a new user, a group is created that contains just that user, and it has the same name as the user. This is the user's "primary group." A user is automatically a member of his or her primary group, as listed in /etc/passwd (see Chapter 9).

These primary groups do not appear in /etc/group. The only record of their existence is in the primary group field of /etc/passwd. This is arguably one of the most annoying things about primary groups, but adding a line to /etc/group for every single user can make the group file difficult to manage.

For example, when the user "pbardaville" is added, the system creates a group "pbardaville" and assigns the user pbardaville to it. This entry appears only in /etc/passwd.

This might seem complicated, but just remember that /etc/passwd trumps /etc/group, and you'll have it.

Some Interesting Default Groups

FreeBSD ships with several default groups. Most are used by the system, and aren't of huge concern to a sysadmin. Still, rather than have them remain mysterious, I present for your amusement the most useful, interesting, and curious. Adding your own groups simplifies administration, but the groups listed here are available on every FreeBSD system.

bin Group for general programs

daemon Group used by various system services, such as the printing system dialer Group of users who can access serial ports

games Group for games programs and files

kmem Group used by programs that have to access kernel memory, such as fstat(1), netstat(1), and so on

mail Group for programs that handle mail operations

man Unused in modern BSD, but corresponds to the man user news Group for Usenet news programs

nobody Group for user ID with no privileges

143

nogroup Group with no privileges

operator Group that can access drives, generally for backup purposes staff Group for system staff

tty Group for programs that can write to terminals, such as wall(1)

wheel Group for users permitted to use the root password. If a user has the root password, but is not in the wheel group, she cannot use su to become root.

Group Permissions

You can assign particular permissions to groups, and all users in that group inherit those permissions. The permissions on a file are also called its mode.

The UNIX permission scheme says that every file has three sets of permissions: owner, group, and other. View the existing file permissions with the −l flag to ls(1):

..........................................................................................

# ls −l
total 29
−rwxr−xr−− 1 mwlucas admins 1188	Sep 14	09:35 file1
−rw−−−−−−− 1 mwlucas admins 27136	Sep 14	09:36 file2
drwxr−xr−x 2 mwlucas admins 512	Sep 14	09:52 otherstuff
#

..........................................................................................

As seen in this listing, the first line ("total 29") displays the number of 512−byte disk blocks the files use. (One block in this case is half a KB, or about a two−thousandth of a MB.) This particular directory has two files, file1 and file2, each of which appears on its own line, with some basic information and its permissions. The permissions on these files appear at the beginning of each line, in the long lines with r's, w's, and x's, like "−rwxr−xr−−".

The permissions control how each group can use the file, and they're of three types: read (r), write (w), and execute (x). The right to read means that you can view or copy the file. Permission to write means that you can alter or overwrite the file. Execute permission means that you can run the file as a program—all programs are executable files. Any entry that is a hyphen (−) means that the user does not have execute permission on that file.

The last entry, otherstuff, is a directory. You can tell it's a directory because the first entry in the permissions line is the letter "d". Directory permissions control who can use the directory in the same way file permissions control who can use the file.

Following the permissions is the number of links to the file. We will discuss links in Chapter 13. Then you'll see the file's owner and group. The number of bytes in the file comes next, followed by the date and time the file was last modified. Finally, you have the actual filename.

When combined with owners and groups, permissions are very flexible. For example, you could place a set of files in a group called www, then give the www group permission to read and write to those files, thereby allowing anyone in the www group to edit them. With this setup, you could give your webmasters control of your company Web site, not allow other users to tamper with the pages, and avoid giving root access to the www group.

144