Networking / Beginners

---

Chroot

The chroot command runs a service with an alternative root directory. For example, if the DNS bind service was launched with chroot under the alternative directory of /opt/dns/, when the bind process refers to the / directory, it will really be accessing the /opt/dns/ directory. The bind configuration file, normally at /var/named.conf will need to be copied to /opt/dns/var/named.conf. The same is true for all files (libraries, executables, and data) that bind will need to run.

The security gains are well worth the effort of setting up the alternative root directory. Now, if compromised, the service will only have at risk the files in the alternative root directory and all subdirectories. The service cannot "see" above the alternate root directory and neither will the attacker. This can be a huge security advantage, because only the minimal number of supporting files needs to be put in the alternative root directory tree to support the service. This limits the data that the attacker has access to. Also, if the service is compromised, the attacker is less likely to be able to spread the attack to other services on the host.

The service is launched by chroot with the following command:

chroot <alternative root directory> <service with command line options>

The alternative root directory setup is not trivial. Any supporting file that the service will need must be copied into the new data structure. This may include a reduced /bin, /usr/lib, and /usr/local, among others.

Root access

Recall from earlier discussions on the kernel that UNIX has only two modes: supervisor (root) and normal (user). In this scheme, root has complete control and access over the entire workstation. For the user, on the other hand, not only is their access restricted, but if a user-run application attempts to access memory that is restricted to root access, a segmentation fault will occur stopping the attempt.

It should, therefore, be obvious that attacks on a UNIX workstation focus around getting root access. To reduce the risk to the workstation, system administrators should be reluctant to provide root access to users. Following are some of the problems that can arise if a normal user has root access:

• Users with root access can change the configuration of the workstation and potentially alter the security controls that the system administrator put in place. For example, a particular service may have been set up to only run in an alternative root directory with chroot. If a user unknowingly launches the service from the command line, this chroot protection will be lost.
• Users may launch services that open the workstation up to potential attacks. For example, Web servers are high-visibility targets and require significant hardening and configuration to be secure. The typical user will not apply the needed level of security for their locally run web server.
• Simple mistakes made by the user can be magnified. Every administrator at one time or another has lost track of the directory they were in and inadvertently run the following command: rm -rf *. This, if you don't recognize it, will delete every (non-hidden) file in the current directory and recursively into all subdirectories, without question. Generally, administrators learn these lessons early on and such control (power) is safe in their hands. However, this may not be the case for the average user. This example is the very kind of thing that can be minimized if the user is logged in as other than root. The user can still do a lot of damage, but it is usually self-inflicted and probably will not delete files owned and controlled by root.

Several steps can be taken to limit the use of the root account on a UNIX workstation. The following lists a couple of the key steps:

• Limit access to the workstation directly as root-All users should be required to log in to the workstation under their limited privilege user account and then su to root if they need to do root-level activities. This can be done by setting the root login shell to /sbin/nologin in the /etc/passwd file. The su command is sometimes referred to as the super user command because it allows a normal user to assume root-level privileges, assuming that the proper root password is provided.
• Limit remote access to the workstation by root-Services that permit remote login, such as sshd, should be configured not to allow root. The system administrator will have to log in as a normal user and then su to root. Each service has its own configuration method, but in the case of sshd, root access is controlled by adding the line PermitRootLogin no to the /etc/ssh/sshd_config file.

Denying root the ability to log in directly to the UNIX workstation has some important effects from a security perpective, as follows:

• The activity conducted by root can be attributed to an individual. The logs on the workstation will log the normal user's login and their transition to root via su. Should a problem arise from the activity, an individual can be queried to account for the changes made.
• If the root password is compromised and acquired by a normal user, they will not be able to use it to log in directly as root.
• Because any user must su to root to perform root-level activities, limiting the users that can run su can add a layer of protection. This is done by controlling which users are in the wheel group in the /etc/group file, because only these users are permitted to su to root. So, even if a normal user acquires the root password, they can be prevented from getting root access, through the su command, by not being put into the wheel group.

The protections discussed so far-limit root's direct access and control which users are in the wheel group-add significant security to the workstation. But these security gains can be reduced if every user is added to the wheel group (granting every user the ability to su to root). This can easily happen if the average user needs to perform a relatively trivial root activity. A good example of this is mounting a cdrom or floppy. Because of one activity (mounting), all users might be given root-level access (put into the wheel group). This is obviously a security risk. The solution to this problem is the sudo command.

The sudo command allows normal users to execute certain commands that would normally be limited to root. In the case of mounting a floppy, the command would be as follows:

sudo mount /dev/fd0 /mnt/floppy

Now certain users will be able to execute a limited number of root-level commands. The system administrator controls which users and which commands can be run by sudo through the configuration file /etc/sudoers.