Securing Linux

previous Terms in Securing Linux

To secure your Linux system, you have to pay attention to both host security and network security. The distinction between the two types of security is somewhat arbitrary because securing the network involves securing the applications on the host that relate to what Internet services your system offers.

This chapter first examines host security and then explains how you can secure network services (mostly by not offering unnecessary services), how you can use a firewall to stop unwanted network packets from reaching your network, and how to use Secure Shell for secure remote logins.

Host is the techie term for your Linux system — especially when you use it to provide services on a network. But the term makes sense even when you think of the computer by itself; it’s the host for everything that runs on it: the operating system and all applications. A key aspect of computer security is to secure the host.

Securing Passwords

Historically, UNIX passwords are stored in the /etc/passwd file, which any user can read. For example, a typical old-style /etc/passwd file entry for the root user looks like this:

root:t6Z7NWDK1K8sU:0:0:root:/root:/bin/bash

The fields are separated by colons (:), and the second field contains the password in encrypted form. To check whether a password is valid, the login program encrypts the plain-text password the user enters and compares the password with the contents of the /etc/passwd file. If they match, the user is allowed to log in.

Password-cracking programs work just like the login program, except that these programs choose one word at a time from a dictionary, encrypt the word, and compare the encrypted word with the encrypted passwords in the /etc/passwd file for a match. To crack the passwords, the intruder needs the /etc/passwd file. Often, crackers use weaknesses of various Internet servers (such as mail and FTP) to get a copy of the /etc/passwd file.

Passwords have become more secure in Linux due to several improvements, including shadow passwords and pluggable authentication modules, or PAMs (described in the next two sections). You can install shadow passwords or a PAM easily while you install Linux. During Linux installation, you typically get a chance to configure the authentication. If you enable MD5 security and enable shadow passwords, you automatically enable more secure passwords in Linux.

Shadow passwords

Obviously, leaving passwords lying around where anyone can get at them — even if the passwords are encrypted — is bad security. So instead of storing passwords in the /etc/passwd file (which any user can read), Linux now stores them in a shadow password file, /etc/shadow. Only the superuser (root) can read this file. For example, here’s the entry for root in the newstyle /etc/passwd file:

root:x:0:0:root:/root:/bin/bash

In this case, note that the second field contains an x instead of an encrypted password. The x is the shadow password; the actual encrypted password is now stored in the /etc/shadow file, where the entry for root is like this:

root:$1$AAAni/yN$uESHbzUpy9Cgfoo1Bf0tS0:11077:0:99999:7:-1:-1:134540356

The format of the /etc/shadow entries with colon-separated fields resembles the entries in the /etc/passwd file, but the meanings of most of the fields differ. The first field is still the username, and the second one is the encrypted password.

The remaining fields in each /etc/shadow entry control when the password expires. You don’t have to interpret or change these entries in the /etc/shadow file. Instead, use the chage command to change the password expiration information. For starters, you can check a user’s password expiration information by using the chage command with the -l option, as follows. (In this case, you have to be logged in as root.)

chage -l root

This command displays expiration information, including how long the password lasts and how often you can change the password.

If you want to ensure that the user is forced to change a password at regular intervals, you can use the -M option to set the maximum number of days that a password stays valid. For example, to make sure that user kdulaney is prompted to change the password in 90 days, log in as root and type the following command:

chage -M 90 kdulaney

You can use the command for each user account to ensure that all passwords expire when appropriate and that all users must choose new passwords.

Pluggable authentication modules (PAMs)

In addition to improving the password file’s security by using shadow passwords, Linux also improves the encryption of the passwords stored in the /etc/shadow file by using the MD5 message-digest algorithm described in RFC 1321 (www.ietf.org/rfc/rfc1321.txt or www.cse.ohio-state. edu/cgi-bin/rfc/rfc1321.html). MD5 reduces a message of any length to a 128-bit message digest (or fingerprint) of a document so that you can digitally sign it by encrypting it with your private key. MD5 works quite well for password encryption, too.

Another advantage of MD5 over older-style password encryption is that the older passwords were limited to a maximum of eight characters; new passwords (encrypted with MD5) can be much longer. Longer passwords are harder to guess, even if the /etc/shadow file falls into the wrong hands.

You can tell that MD5 encryption is in effect in the /etc/shadow file. The encrypted passwords are longer and they all sport the $1$ prefix, as in the second field of the following sample entry:

root:$1$AAAni/yN$uESHbzUpy9Cgfoo1Bf0tS0:11077:0:99999:7:-1:-1:134540356

An add-on program module called a pluggable authentication module (PAM) performs the MD5 encryption. Linux PAMs provide a flexible method for authenticating users. By setting the PAM’s configuration files, you can change your authentication method on-the-fly, without modifying vital programs that verify a user’s identity (such as login and passwd).

Linux uses PAM capabilities extensively. The PAMs reside in many different modules (more on this momentarily); their configuration files are in the /etc/pam.d directory of your system. Check out the contents of this directory on your system by typing the following command:

ls /etc/pam.d

Each configuration file in this directory specifies how users are authenticated for a specific utility.

Protecting Files and Directories

One important aspect of securing the host is to protect important system files — and the directories that contain these files. You can protect the files through file ownership and the permission settings that control who can read, write, or (in the case of executable programs) execute the file.

The default Linux file security is controlled through the following settings for each file or directory:

• User ownership
• Group ownership
• Read, write, execute permissions for the owner
• Read, write, execute permissions for the group
• Read, write, execute permissions for others (everyone else)

Viewing ownerships and permissions

You can see settings related to ownership and permissions for a file when you look at a detailed listing with the ls -l command. For example, type the following command to see the detailed listing of the /etc/inittab file:

ls -l /etc/inittab

The resulting listing looks something like this:

-rw-r--r-- 1 root root 1666 Feb 16 07:57 /etc/inittab

The first set of characters describes the file permissions for user, group, and others. The third and fourth fields show the user and group that own this file. In this case, both user and group names are the same: root.

Changing file ownerships

You can set the user and group ownerships with the chown command. For example, if the file /dev/hda should be owned by the user root and the group disk, you type the following command as root to set up this ownership:

chown root.disk /dev/hda

To change the group ownership alone, use the chgrp command. For example, here’s how you can change the group ownership of a file from whatever it was earlier to the group named accounting:

chgrp accounting ledger.out

Changing file permissions

Use the chmod command to set the file permissions. To use chmod effectively, you have to specify the permission settings. One way is to concatenate one or more letters from each column of Table 2-1, in the order shown (Who/Action/Permission).

Table 2-1	File Permission Codes
Who	Action	Permission
u (user)	+ (add)	r (read)
g (group)	- (remove)	w (write)
o (others)	= (assign)	x (execute)
a (all)	s (set user ID)

To give everyone read and write access to all files in a directory, type chmod a+rw *. On the other hand, to permit everyone to execute a specific file, type chmod a+x filename.

Another way to specify a permission setting is to use a three-digit sequence of numbers. In a detailed listing, the read, write, and execute permission settings for the user, group, and others appear as the sequence

rwxrwxrwx

with dashes in place of letters for disallowed operations. Think of rwxrwxrwx as three occurrences of the string rwx. Now assign the values r=4, w=2, and x=1. To get the value of the sequence rwx, simply add the values of r, w, and x.

Thus, rwx = 7. With this formula, you can assign a three-digit value to any permission setting. For example, if the user can read and write the file but everyone else can only read the file, the permission setting is rw-r--r-(that’s how it appears in the listing), and the value is 644. Thus, if you want all files in a directory to be readable by everyone but writable only by the user, use the following command:

chmod 644 *

Setting default permission

What permission setting does a file get when you (or a program) create a new file? The answer is in what is known as the user file-creation mask, which you can see and set by using the umask command.

Type umask, and the command prints a number showing the current filecreation mask. For the root user, the mask is set to 022, whereas the mask for other users is 002. To see the effect of this file-creation mask and to interpret the meaning of the mask, follow these steps:

1. Log in as root and type the following command:
   touch junkfile
   This command creates a file named junkfile with nothing in it.

2. Type ls -l junkfile to see that file’s permissions.
   You see a line similar to the following:
   -rw-r--r-- 1 root root 0 Aug 24 10:56 junkfile
   Interpret the numerical value of the permission setting by converting each three-letter permission in the first field (excluding the very first letter) to a number between 0 and 7. For each letter that’s present, the first letter gets a value of 4, the second letter is 2, and the third is 1. For example, rw- translates to 4+2+0 (because the third letter is missing), or 6. Similarly, r-- is 4+0+0 = 4. Thus the permission string -rw-r--r--becomes 644.

3. Subtract the numerical permission setting from 666 and what you getis t he umask setting.
   In this case, 666 – 644 results in a umask of 022.

Thus, a umask of 022 results in a default permission setting of 666 - 022 = 644. When you rewrite 644 in terms of a permission string, it becomes rw-r--r--.

To set a new umask, type umask followed by the numerical value of the mask. Here is how you go about it:

1. Figure out what permission settings you want for new files.
   For example, if you want new files that can be read and written only by the owner and no one else, the permission setting looks like this:
   rw-------

2. Convert the permissions into a numerical value by using the conversion method that assigns 4 to the first field, 2 to the second, and 1 to the third.
   Thus, for files that are readable and writable only by their owner, the permission setting is 600.

3. Subtract the desired permission setting from 666 to get the value of the mask.
   For a permission setting of 600, the mask becomes 666 – 600 = 066.

4. Use the umask command to set the file-creation mask by typing

   umask 066

A default umask of 022 is good for system security because it translates to files that have read and write permission for the owner and read permissions for everyone else. The bottom line is that you don’t want a default umask that results in files that are writable by the whole world.

Checking for set user ID permission

Another permission setting can be a security hazard. This permission setting, called the set user ID (or setuid for short), applies to executable files. When the setuid permission is enabled, the file executes under the user ID of the file’s owner. In other words, if an executable program is owned by root and the setuid permission is set, the program runs as if root is executing it — no matter who executed the program. The setuid permission means that the program can do a lot more (for example, read all files, create new files, and delete files) than what a normal user program can do. Another risk is that if a setuid program file has a security hole, crackers can do a lot more damage through such programs than through other vulnerabilities.

You can find all setuid programs with a simple find command:

find / -type f -perm +4000 -print

You see a list of files such as the following:

/bin/su
/bin/ping
/bin/eject
/bin/mount
/bin/ping6
/bin/umount
/opt/kde3/bin/fileshareset
/opt/kde3/bin/artswrapper
/opt/kde3/bin/kcheckpass
. . . lines deleted . . .

Many of the programs have the setuid permission because they need it, but check the complete list and make sure that there are no strange setuid programs (for example, setuid programs in a user’s home directory).

For example, if you type ls -l /bin/su, you see the following permission settings:

-rwsr-xr-x 1 root root 25756 Aug 19 17:06 /bin/su

The s in the owner’s permission setting (-rws) tells you that the setuid permission is set for the /bin/su file, which is the executable file for the su command that you can use to become root or another user.

next Encrypting and Signing Files with GnuPG