Combine chroot and Your Distribution s Security Capabilities


Secure shell access on a system with many users may seem like a prime candidate for a chroot execution, but in this case the administrator may want to simply rely on the privilege separation capabilities inherent to OpenSSH. Privilege separation was established as part of the default configuration starting with version OpenSSH-3.3p1. Privilege separation follows a similar concept of Apache s reduced privilege execution once the server has been bound to a port. In the case of OpenSSH, the daemon uses an unprivileged account (UID > 0) to perform network and user request processing. Thus, the result of an exploit in the key exchange, authentication, or shell interaction will be limited to a restricted, non-root environment.

Of course, there are other reasons for establishing a chroot environment. The administrator may want to provide users with an interactive shell, but limit access to the full resources and utilities of the operating system. While privilege separation provides a defense against compromise, it does not impose restrictions on the shell and resources available to users.

pam_chroot and Red Hat Enterprise Linux AS 3.0

Red Hat Enterprise Linux AS 3.0 contains a pluggable authentication module (PAM) that enables administrators to set up chroot environments for users who remotely log in to the system. This plug-in, pam_chroot , uses the system s core files (such as /etc/passwd and /etc/shadow) to authenticate users, but then hands off the user into a restricted portion of the file system. This has the significant advantage that users passwords can be stored outside of the chroot environment.

Select the service you want to chroot from the /etc/pam.d/ directory. We will use SSH in this example. Each file in the /etc/pam.d/ directory contains PAM directives to authenticate (identify the user and check a password) and define actions for the session (logging, quotas, chroot , and so on). All PAM plug-ins are located in the /lib/security/ directory. Add a new session entry in the PAM file that applies pam_chroot to the user s login procedure. This line is shown in bold:

 # cat /etc/pam.d/sshd #%PAM-1.0 auth       required     pam_stack.so service=system-auth auth       required     pam_nologin.so account    required     pam_stack.so service=system-auth password   required     pam_stack.so service=system-auth session    required     pam_stack.so service=system-auth session    required     pam_limits.so  session    required     pam_chroot.so onerr=fail debug  session    optional     pam_console.so 

There are two arguments passed to this module. The onerr=fail argument instructs PAM to explicitly fail if it encounters any errors while processing the chroot switch. The debug argument provides additional information to syslog if you have difficulty setting up the environment. Even though this module is required , it will not be applied to a user unless that user s name is defined in the /etc/security/chroot.conf file. Thus, user authentication still occurs normally for all users (including root) until further configuration steps are taken.

The format of the /etc/security/chroot.conf is simple. Each row contains two columns . The first column contains a specific username or regular expression that matches multiple usernames. The second column contains the root directory used for the chroot switch. Here is an example:

 # /etc/security/chroot.conf # format: # username_regex        chroot_dir mike                    /opt/chroot 

There is an important caveat when combining pam_chroot and SSH. Nearly all current OpenSSH installations use PrivilegeSeparation by default. The pam_chroot plug-in requires root privileges to establish a restricted environment via SSH. This means that you cannot use PrivilegeSeparation without significant configuration changes, because the listening process runs as the sshd user instead of root. If the SSH daemon is using privilege separation, you will see an error in /var/log/secure similar to this:

 pam_chroot[  pid  ]: chroot(/opt/chroot) failed: Operation not permitted 

Therefore, ensure that PrivilegeSeparation is disabled in /etc/ssh/sshd_config:

 UsePrivilegeSeparation no 

This presents a policy decision in which you must weigh the pros and cons of running SSH processes with root privileges and restricted user environments or running SSH listening processes with reduced privileges and restricted user environments. PrivilegeSeparation is designed to reduce the impact of a zero-day exploit against the daemon and underlying system. pam_chroot is designed to reduce the impact of a compromise against a user account and the underlying system.

The only remaining step to complete the implementation of pam_chroot is to establish a proper user environment in /opt/chroot. Place the binaries and dynamic libraries within /opt/chroot as described previously in this chapter. Also, remember to create a /dev/pts entry, otherwise users will not be able to log in. The /dev/pts handles the pseudo-terminals assigned to users when they log in to a system.

 # mkdir p /opt/chroot/dev/pts  # mount t devpts devpts /opt/chroot/dev/pts 

Of course, a more complete device structure can be built with the MAKEDEV command, but this will not create the necessary /dev/pts entry:

 # /dev/MAKEDEV -d /opt/chroot/dev/ generic 

The remainder of the user environment must still be created. Remember that the /etc/passwd and /etc/ group files are necessary, but /etc/shadow is not.

Monitor File Mode and Permission Settings

Mandrake s msec utility is a collection of Python scripts and cron jobs that continuously monitor security settings. With regard to chroot , msec comes in handy for ensuring that the file permissions and modes do not change.

Although msec does not exist on Red Hat or SUSE, its concept can be adopted and implemented with cron jobs and scripts that just focus on the chroot directory. In fact, this step is merely an extension of the policy you use to monitor sensitive files on the base file system. If a tool like msec or tripwire is used for the base operating system, then it should be adopted for the chroot service as well.

msec is executed by the host operating system. Define the settings in the /etc/security/msec/perm.local file (this file might not be present by default). If you re unsure of how to set up this file, refer to the default settings for each perm.* file in the /usr/share/msec directory. Each perm.* file corresponds to an msec security level (0 “5). The settings in /etc/security/msec/perm.local supersede the perm.* value for the current level.

 # Some msec file permission entries. # File or Directory             owner.group            mode /opt/chroot/                    root.root               711 /opt/chroot/bin/                root.root               711 /opt/chroot/etc/                root.root               711 /opt/chroot/etc/ftpaccess       root.root               600 /opt/chroot/etc/ftpconversions  root.root               600 /opt/chroot/etc/ftpgroups       root.root               600 /opt/chroot/etc/ftphosts        root.root               600 /opt/chroot/etc/ftpusers        root.root               600 /opt/chroot/etc/hosts.allow     root.daemon             644 /opt/chroot/etc/hosts.deny      root.daemon             644 /opt/chroot/etc/hosts.equiv     root.daemon             640 /opt/chroot/etc/ld.so.conf      root.root               600 

The /etc/security/msec/level.local file toggles specific msec checks. These will be less useful for the chroot environment. For example, password and shadow file checks are performed on the host, not the chroot environment. Still, it s a good idea to be aware of additional security options you can set for the host system.




Hardening Linux
Hardening Linux
ISBN: 0072254971
EAN: 2147483647
Year: 2004
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net