A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

---

Running a Service in a chroot Jail

Running a shell inside a jail has limited usefulness. In reality, you are more likely to want to run a specific service inside the jail. To run a service inside a jail, make sure all files needed by that service are inside the jail. Using uchroot, the format of a command to start a service in a chrootjail is

# /usr/local/bin/uchroot user jailpath daemonname

where jailpath is the pathname of the jail directory, user is the username that runs the daemon, and daemonname is the pathname (inside the jail) of the daemon that provides the service.

Some servers are already set up to take advantage of chroot jails. For example, you can set up DNS so that named runs in a jail (page 883), and the vsftpd FTP server can automatically start chroot jails for clients (page 729).

Security Considerations

Some services need to be run by a user or process with root privileges but release their root privileges once started (Apache, Procmail, and vsftpd are examples). If you are running such a service, you do not need to use uchroot or put su or sudo inside the jail.

A process run with root privileges can potentially escape from a chroot jail. For this reason, you should reduce privileges before starting a program running inside the jail. Also, be careful about which setuid (page 196) binaries you allow inside a jail—a security hole in one of them could compromise the security of the jail. In addition, make sure the user cannot access executable files that he uploads to the jail.

DHCP: Configures Network Interfaces

Instead of storing network configuration information in local files on each system, DHCP (Dynamic Host Configuration Protocol) enables client systems to retrieve the necessary network configuration information from a DHCP server each time they connect to the network. A DHCP server assigns IP addresses from a pool of addresses to clients as needed. Assigned addresses are typically temporary but need not be.

This technique has several advantages over storing network configuration information in local files:

• A new user can set up an Internet connection without having to deal with IP addresses, netmasks, DNS addresses, and other technical details. An experienced user can set up a connection more quickly.

• DHCP facilitates assignment and management of IP addresses and related network information by centralizing the process on a server. A system administrator can configure new systems, including laptops that connect to the network from different locations, to use DHCP; DHCP then assigns IP addresses only when each system connects to the network. The pool of IP addresses is managed as a group on the DHCP server.

• DHCP facilitates the use of IP addresses by more than one system, reducing the total number of IP addresses needed. This conservation of addresses is important because the Internet has run out of IPv4 addresses. Although a particular IP address can be used by only one system at a time, many end-user systems require addresses only occasionally, when they connect to the Internet. By reusing IP addresses, DHCP has lengthened the life of the IPv4 protocol.

DHCP is particularly useful for an administrator who is responsible for maintaining a large number of systems because new systems no longer need to be set up with unique configuration information.

How DHCP Works

Using dhclient, the client contacts the server daemon, dhcpd, to obtain the IP address, netmask, broadcast address, nameserver address, and other networking parameters. In turn, the server provides a lease on the IP address to the client. The client can request the specific terms of the lease, including its duration; the server can limit these terms. While connected to the network, a client typically requests extensions of its lease as necessary so its IP address remains the same. This lease might expire once the client is disconnected from the network, with the server giving the client a new IP address when it requests a new lease. You can also set up a DHCP server to provide static IP addresses for specific clients (refer to “Static Versus Dynamic IP Addresses” on page 298).

When you start Fedora/RHEL, the system runs a DHCP client, connects to a DHCP server if it can find one, and configures its network interface.

DHCP Client

A DHCP client requests network configuration parameters from the DHCP server and uses those parameters to configure its network interface.

Prerequisites

Make sure the following package is installed:

• dhclient

dhclient: The DHCP Client

When a DHCP client system connects to the network, dhclient requests a lease from the DHCP server and configures the client’s network interface(s). Once a DHCP client has requested and established a lease, it stores the lease information in a file named dhclient-*-interface.lease, which resides in the /var/lib/NetworkManager directory. The interface is the name of the interface the client uses, such as eth0. The system uses this information to reestablish a lease when either the server or the client needs to reboot. The DHCP client configuration file, /etc/dhcp/dhclient.conf, is required only for custom configurations. The /usr/share/doc/dhclient* directory holds a well-commented dhclient.conf file.

The following dhclient.conf file specifies a single interface, ens33:

$ cat /etc/dhcp/dhclient.conf
interface "ens33"
{
send dhcp-client-identifier 1:xx:xx:xx:xx:xx:xx;
send dhcp-lease-time 86400;
}

In the preceding file, the 1 in the dhcp-client-identifier specifies an Ethernet network and xx:xx:xx:xx:xx:xx is the MAC address (page 1259) of the device controlling that interface. See page 494 for instructions on how to determine the MAC address of a device. The dhcp-lease-time is the duration, in seconds, of the lease on the IP address. While the client is connected to the network, dhclient automatically renews the lease each time half of the lease time is up. A lease time of 86,400 seconds (one day) is a reasonable choice for a workstation.

DHCP Server

A DHCP server maintains a list of IP addresses and other configuration parameters. Clients request network configuration parameters from the server. The DHCP server does not ship with a working configuration. See the /usr/share/doc/dhcp*/*example files for sample dhcpd.conf files that include a lot of documentation.

Prerequisites

Install the following package:

• dhcp

Enable and start dhcpd

Run systemctl to cause the dhcpd service (dhcpd daemon) to start each time the system enters multiuser mode and then start the dhcpd service. Use the systemctl status command to make sure the service is running.

# systemctl enable dhcpd.service
# systemctl start dhcpd.service

After modifying dhcpd configuration files, give the second command again, replacing start with restart to cause dhcpd to reread those files.

dhcpd: The DHCP Daemon

A simple DHCP server (dhcpd) allows you to add clients to a network without maintaining a list of assigned IP addresses. A simple network, such as a home-based LAN sharing an Internet connection, can use DHCP to assign a dynamic IP address to almost all nodes. The exceptions are servers and routers, which must be at known network locations if clients are to find them. If servers and routers are configured without DHCP, you can specify a simple DHCP server configuration in /etc/dhcp/dhcpd.conf:

$ cat /etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 86400;

option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option domain-name "example.com";

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.2 192.168.1.200;
}

By default, dhcpd serves requests on all nonbroadcast network interfaces.

The preceding configuration file specifies a LAN where both the router and the DNS server are located on 192.168.1.1. The default-lease-time specifies the number of seconds the dynamic IP lease will remain valid if the client does not specify a duration. The max-lease-time is the maximum time allowed for a lease.

The information in the option lines is sent to each client when it connects. The names following the word option specify what the following argument represents. For example, the option broadcast-address line specifies the broadcast address of the network. The routers and domain-name-servers options can be followed by multiple values separated by commas.

The subnet section includes a range line that specifies the range of IP addresses the DHCP server can assign. In the case of multiple subnets, you can define options, such as subnet-mask, inside the subnet section. Options defined outside all subnet sections are global and apply to all subnets.

The preceding configuration file assigns addresses in the range from 192.168.1.2 to 192.168.1.200. The DHCP server starts at the bottom of this range and attempts to assign a new IP address to each new client. Once the DHCP server reaches the top of the range, it starts reassigning IP addresses that have been used in the past but are not currently in use. If you have fewer systems than IP addresses, the IP address of each system should remain fairly constant. Two systems cannot use the same IP address at the same time.

Once you have configured a DHCP server, restart it using systemctl (previous page). When the server is running, clients configured to obtain an IP address from the server using DHCP should be able to do so. See the /usr/share/doc/dhcp*/*example files for sample dhcpd.conf files.

Static IP Addresses

As mentioned earlier, routers and servers typically require static IP addresses. Although you can manually configure IP addresses for these systems, it might be more convenient to have the DHCP server provide them with static IP addresses. See page 641 if you want to configure a system to use a static IP address without using DHCP.

When a system that requires a specific static IP address connects to the network and contacts the DHCP server, the server needs a way to identify the system so it can assign the proper IP address to that system. The DHCP server uses the MAC address (page 1259) of the system’s NIC (network interface card) as an identifier. When you set up the server, you must know the MAC address of each system that requires a static IP address.

Determining a MAC address

The ip utility displays the MAC addresses of the Ethernet cards in a system. In the following example, the MAC address is the colon-separated series of hexadecimal number pairs following link/ether:

$ ip link show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 00:0c:29:13:f4:35 brd ff:ff:ff:ff:ff:ff

Run ip on each system that requires a static IP address. Once you have determined the MAC addresses of these systems, you can add a host section to the /etc/dhcp/ dhcpd.conf file for each one, instructing the DHCP server to assign a specific address to that system. The following hostsection assigns the address 192.168.1.1 to the system with the MAC address of BA:DF:00:DF:C0:FF:

$ cat /etc/dhcp/dhcpd.conf
...
host router {
hardware ethernet BA:DF:00:DF:C0:FF;
fixed-address 192.168.1.1;
option host-name router;
}

The name following host is used internally by dhcpd. The name specified after option host-name is passed to the client and can be a hostname or an FQDN. After making changes to dhcpd.conf, restart dhcpd using systemctl (previous page).

nsswitch.conf: Which Service to Look at First

Once NIS and DNS were introduced, finding user and system information was no longer a simple matter of searching a local file. When once you looked in /etc/passwd to get user information and in /etc/hosts to find system address information, now you can use several methods to obtain this type of information. The /etc/nsswitch.conf (name service switch configuration) file specifies which methods to use and the order in which to use them when looking for a certain type of information. You can also specify which action the system should take based on whether a method succeeds or fails.

Syntax

Each line in nsswitch.conf specifies how to search for a piece of information, such as a user’s password. A line in nsswitch.conf has the following syntax:

info: method [[action]] [method [[action]]...]

where info is the type of information the line describes, method is the method used to find the information, and action is the response to the return status of the preceding method. The action is enclosed within square brackets.

When called upon to supply information that nsswitch.conf describes, the system examines the line with the appropriate info field. It uses the methods specified on this line, starting with the method on the left. By default, when it finds the desired information, the system stops searching. Without an action specification, when a method fails to return a result, the system tries the next action. It is possible for the search to end without finding the requested information.

Information

The nsswitch.conf file commonly controls searches for usernames, passwords, host IP addresses, and group information. The following list describes most of the types of information (info in the syntax given earlier) that nsswitch.conf controls searches for:

Methods

Following is a list of the methods that nsswitch.conf uses to search for information (method in the syntax shown on the previous page). For each type of information, you can specify one or more of the following methods:²

2. Other, less commonly used methods also exist. See the default /etc/nsswitch.conf file and the nsswitch.conf man page for more information. Although NIS+ belongs in this list, it is not implemented as a Linux server and is not discussed in this book.

Search Order

The information provided by two or more methods might overlap: For example, both files and nis might provide password information for the same user. With overlapping information, you need to consider which method you want to be authoritative (take precedence) and then place that method at the left of the list of methods.

The default nsswitch.conf file lists methods without actions, assuming no overlap (which is normal). In this case, the order is not critical: When one method fails, the system goes to the next one and all that is lost is a little time. Order becomes critical when you use actions between methods or when overlapping entries differ.

The first of the following lines from nsswitch.conf causes the system to search for password information in /etc/passwd and if that fails, to use NIS to find the information. If the user you are looking for is listed in both places, the information in the local file is used and is considered authoritative. The second line uses NIS to find an IP address given a hostname; if that fails, it searches /etc/hosts; if that fails, it checks with DNS to find the information.

passwd files nis
hosts nis files dns

Action Items

Each method can optionally be followed by an action item that specifies what to do if the method succeeds or fails. An action item has the following format:

[[!]STATUS=action]

where the opening and closing square brackets are part of the format and do not indicate that the contents are optional; STATUS (uppercase by convention) is the status being tested for; and action is the action to be taken if STATUS matches the status returned by the preceding method. The leading exclamation point (!) is optional and negates the status.

STATUS

STATUS might have any of the following values:

NOTFOUND—The method worked, but the value being searched for was not found. The default action is continue.

SUCCESS—The method worked, and the value being searched for was found; no error was returned. The default action is return.

TRYAGAIN—The method failed because it was temporarily unavailable. For example, a file might be locked or a server overloaded. The default action is continue.

UNAVAIL—The method failed because it is permanently unavailable. For example, the required file might not be accessible or the required server might be down. The default action is continue.

action

There are two possible values for action:

return—Returns to the calling routine with or without a value.

continue—Continues with the next method. Any returned value is overwritten by a value found by a subsequent method.

Example

The following line from nsswitch.conf causes the system first to use DNS to search for the IP address of a given host. The action item following the DNS method tests whether the status returned by the method is not (!) UNAVAIL.

hosts dns [!UNAVAIL=return] files

The system takes the action associated with the STATUS (return) if the DNS method does not return UNAVAIL (!UNAVAIL)—that is, if DNS returns SUCCESS, NOTFOUND, or TRYAGAIN. As a consequence, the following method (files) is used only when the DNS server is unavailable. If the DNS server is not unavailable (read the two negatives as “is available”), the search returns the domain name or reports that the domain name was not found. The search uses the files method (checks the local /etc/hosts file) only if the server is not available.

compat Method: ± in passwd, group, and shadow Files

You can put special codes in the /etc/passwd, /etc/group, and /etc/shadow files that cause the system, when you specify the compat method in nsswitch.conf, to combine and modify entries in the local files and the NIS maps. That is, a plus sign (+) at the beginning of a line in one of these files adds NIS information; a minus sign (–) removes information.

For example, to use these codes in the passwd file, specify passwd: compat in the nsswitch.conf file. The system then goes through the passwd file in order, adding or removing the appropriate NIS entries when it reaches each line that starts with a + or –.

Although you can put a plus sign at the end of the passwd file, specify passwd: compat in nsswitch.conf to search the local passwd file, and then go through the NIS map, it is more efficient to put passwd: file nis in nsswitch.conf and not modify the passwd file.

Getting Help

Fedora/RHEL comes with extensive documentation (pages 113 and 128). Fedora maintains a page that points to many useful support documents at docs.fedoraproject.org; fedoraproject.org/en/get-help has links to ask.fedoraproject.org, email lists, and IRC chatrooms; Red Hat maintains a similar page at access.redhat.com and keeps documentation at access.redhat.com/docs. Although some sections of these Red Hat sites require an account to access, anyone can get an account for free. You can also find help on the Linux SIG site (formerly SAGE; www.usenix.org/lisa). The Internet is another rich source of information on managing a Linux system; refer to Appendix B (page 1149) and to the author’s home page (www.sobell.com) for pointers to useful sites.

You need not act as a Fedora/RHEL system administrator in isolation; a large community of Fedora/RHEL experts is willing to assist you in getting the most out of a Linux system. Of course, you will get better help if you have already tried to solve a problem yourself by reading the available documentation. If you are unable to solve a problem by consulting the documentation, a well-thought-out question posed to the appropriate newsgroup (such as comp.os.linux.misc) or mailing list can often generate useful information. Be sure to describe the problem accurately and identify the system carefully. Include information about the version of Fedora/RHEL running on the system and any software packages and hardware you think relate to the problem. The newsgroup comp.os.linux.answers contains postings of solutions to common problems and periodic postings of the most up-to-date versions of FAQs and HOWTO documents. See www.catb.org/~esr/faqs/smart-questions.html for a helpful paper by Eric S. Raymond and Rick Moen titled “How to Ask Questions the Smart Way.”

Chapter Summary

A system administrator is someone who keeps the system in a useful and convenient state for its users. Much of the work you do as the system administrator will require you to work with root privileges. A user with these privileges (sometimes referred to as Superuser) has extensive systemwide powers that normal users do not have. A user with root privileges can read from and write to almost any file and can execute programs that ordinary users are not permitted to execute.

The system administrator controls system operation, including configuring the system; booting up; running systemctl to set up services; working in single-user, multiuser, and rescue modes; bringing the system down; and handling system crashes. Fedora/RHEL provides both graphical and textual configuration tools.

When you bring the system up in single-user mode, only the system console is functional. While working in single-user mode, you can back up files and use fsck to check the integrity of filesystems before you mount them. The systemctl utility can bring the system to its default multiuser state. With the system running in multiuser mode, you can still perform many administration tasks, such as adding users and printers.

When you install a Fedora/RHEL system, you specify a password for the root account. You use this password to gain root privileges, either by logging in as the user named root or by using su and providing the root password. Alternately, you can configure sudo, which grants rootprivileges based on your password. A system that does not have a root password and that relies on sudo to escalate permissions can be more secure than one with a root password.

The systemd init daemon, which replaces the traditional System V init daemon (SysVinit), is event based: It can start and stop services upon receiving information that something on the system has changed (an event). Events include adding devices to and removing them from the system as well as bringing the system up and shutting it down. The systemctl utility works with systemd and can turn services on and off and alter their persistent state (i.e., whether they come up when the system boots).

You can use TCP wrappers to control who can use which system services by editing the hosts.allow and hosts.deny files in the /etc directory. Setting up a chroot jail limits the portion of the filesystem a user sees, so it can help control the damage a malicious user can do.

You can set up a DHCP server so you do not have to configure each system on a network manually. DHCP can provide both static and dynamic IP addresses. Whether a system uses NIS, DNS, local files, or a combination (and in which order) as a source of information is determined by/etc/nsswitch.conf. Linux-PAM enables you to maintain fine-grained control over who can access the system, how they can access it, and what they can do.

Exercises

1. How does single-user mode differ from multiuser mode?

2. How would you communicate each of the following messages?

a. The system is coming down tomorrow at 6:00 in the evening for periodic maintenance.

b. The system is coming down in five minutes.

c. Zach’s jobs are slowing the system down drastically, and he should postpone them.

d. Zach’s wife just had a baby girl.

3. What do the letters of the su command stand for? (Hint: It is not Superuser.) What can you do using su besides give yourself root privileges? How would you log in as Zach if you did not know his password but knew the root password? How would you establish the same environment that Zach has when he first logs in?

4. How would you allow a user to execute a specific, privileged command without giving the user the root password or permission to use sudo to run any command with root privileges?

5. How do you kill process 1648? How do you kill all processes running kmail? In which instances do you need to work with root privileges?

6. How can you disable SELinux?

7. Develop a strategy for coming up with a password that an intruder would not be likely to guess but that you will be able to remember.

Advanced Exercises

8. Give the command:

$ /usr/sbin/fuser -uv /

What does the output list? Why is it so long? Give the same command while working with root privileges (or ask the system administrator to do so and email you the results). How does this list differ from the first? Why is it different?

9. When it puts files in a lost+found directory, fsck has lost the directory information for the files and thus has lost the names of the files. Each file is given a new name, which is the same as the inode number for the file:

$ ls –l lost+found
–rw–r––r–– 1 max pubs 110 06-10 10:55 51262

How can you identify these files and restore them?

10. Take a look at /usr/bin/lesspipe.sh. Explain its purpose and describe six ways it works.

11. Why are root-owned setuid shell scripts inherently unsafe?

12. When a user logs in, you would like the system to first check the local /etc/passwd file for a username and then check NIS. How do you implement this strategy?

13. Some older kernels contain a vulnerability that allows a local user to gain root privileges. Explain how this kind of vulnerability negates the value of a chroot jail.