 | Level: Introductory Robb R. Romans (robb@linux.vnet.ibm.com), Software Engineer, IBM
26 Feb 2008 If you're concerned about protecting world-writeable shared
directories such as /tmp or /var/tmp from abuse, a Linux® Pluggable
Authentication Module (PAM) can help you. The pam_namespace module creates a
separate namespace for users on your system when they login. This separation is
enforced by the Linux operating system so that users are protected from several
types of security attacks. This article for Linux system administrators lays out the
steps to enable namespaces with PAM.
To improve security, it's often wise to use more than one method of protection
(also called "defense in depth"). That way, if one method is breached, another
method remains operational and prevents further intrusion. This article describes
a way to add another layer of depth to your security strategy: using PAM to
polyinstantiate world-writeable shared directories. This means that a new
instance of a directory, such as /tmp, is created for each user.
Polyinstantiation of world-writeable directories prevents the following types of
attacks, as Russell Coker illustrates in "Polyinstantiation of directories in an
SELinux system" (see Resources):
- Race-condition attacks with symbolic links
- Exposing a file name considered secret information or useful to an attacker
- Attacks by one user on another user
- Attacks by a user on a daemon
- Attacks by a non-root daemon on a user
However, polyinstantiation does NOT prevent these types of attacks:
- Attacks by a root daemon on a user
- Attacks by root (account or escalated privilege) on any user
How PAM and polyinstantiation work
PAM creates a polyinstantiated private /tmp directory at login time within a
system instance directory; this redirection is transparent to the user logging in.
The user sees a standard /tmp directory and can read and write to it normally.
That user cannot see any other user's (including root's) /tmp space or the
actual /tmp file system.
Polyinstantiated user directories are neither hidden nor protected from the root
user. If you are interested in that level of protection, SELinux can help. The
configuration examples provided here should work whether or not you have enabled
SELinux. See Resources for links to more information
about using SELinux.
Enabling polyinstantiation
This section shows you how to enable polyinstantiation of /tmp and /var/tmp
directories for users on your system. It also describes the optional configuration
steps necessary to accommodate X Windows or a graphical display manager. I used
Red Hat Enterprise Linux 5.1 (RHEL 5.1) to write this article, but you can try the
procedures described here on any Linux distribution that includes the
pam_namespace module.
First we'll edit namespace.conf.
Edit namespace.conf
The first file you'll edit is /etc/security/namespace.conf, which controls the
pam_namespace module. In this file, list the directories that you want PAM to
polyinstantiate on login. Some example directories are listed in the file included
with PAM and are commented out. Type man namespace.conf
to view a comprehensive manual page. The syntax for each line in this file is
polydir instance_prefix method list_of_uids.
Briefly, here is what these variables represent:
-
polydir is the absolute pathname of the directory
to polyinstantiate.
-
instance_prefix is the base directory of the new
polyinstantiated user directory.
-
method can be user, level, or
context.
-
list_of_uids is a list of user names for which PAM
will NOT polyinstantiate their directories.
In this example, you are not using SELinux, so you must specify the user
for the method. You can use the variables $USER and
$HOME within the configuration file if needed.
Listing 1 creates a private /tmp and /var/tmp namespace instance for each user
on the system except root and adm.
Listing 1. /etc/security/namespace.conf
#$HOME $HOME/$USER.inst/ user root,adm
/tmp /tmp/tmp-inst/ user root,adm
/var/tmp /var/tmp/tmp-inst/ user root,adm
|
The /tmp and /var/tmp directories do not have to be located on separate
filesystems; they can be directories on a single file system. The directories
/tmp/tmp-inst and /var/tmp/tmp-inst must be created once, manually, with file mode
000 before polyinstantiation will work. If the directories are not created
correctly, logins will fail.
Type the following commands while logged in as the root user to create these
directories:
# mkdir /tmp/tmp-inst
# mkdir /var/tmp/tmp-inst
# chown root:root /tmp/tmp-inst /var/tmp/tmp-inst
# chmod 000 /tmp/tmp-inst /var/tmp/tmp-inst
|
Modify PAM
Next, modify the PAM configuration files to add the pam_namspace.so module to
the list of required modules to run on login from the console and from the secure
shell. Edit the /etc/pam.d/login and /etc/pam.d/sshd files to place the
pam_namespace.so module on the last line in each file. Listing 2 and Listing 3
show where to add the module in /etc/pam.d/login and /etc/pam.d/sshd,
respectively:
Listing 2. Adding the PAM module to /etc/pam.d/login
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session include system-auth
session required pam_loginuid.so
#
session optional pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the
user context
session required pam_selinux.so open
session optional pam_keyinit.so force revoke
# Polyinstantiation:
session required pam_namespace.so
|
Listing 3. Adding the PAM module to /etc/pam.d/sshd
#%PAM-1.0
auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
session optional pam_keyinit.so force revoke
session include system-auth
session required pam_loginuid.so
# Polyinstantiation:
session required pam_namespace.so
|
Enable X Windows
Because of the way the X Window system uses temporary directories, graphical
sessions might fail for users with a polyinstantiated /tmp directory. PAM executes
the contents of the /etc/security/namespace.init file during login if
pam_namespace is specified in any files in the /etc/pam.d directory. Use this file
to make the necessary changes to allow X Windows to start correctly. A default
namespace.init file is included with RHEL 5.1, but I have modified it slightly in
Listing 4.
Listing 4. Enables X Windows to start correctly
if [ $1 = /tmp ]; then
if [ ! -f /.tmp/.X11-unix ]; then
mkdir -p /.tmp/.X11-unix
fi
mount --bind /tmp/.X11-unix /.tmp/.X11-unix
[ -f /tmp/.X0-lock ] && cp -fp -- /tmp/.X0-lock "$2/.X0-lock"
mkdir -p -- "$2/.X11-unix"
ln -fs -- /.tmp/.X11-unix/X0 "$2/.X11-unix/X0"
fi
exit 0
|
Configure the Gnome Display Manager
Configuring the Gnome Display Manager (GDM) is easy. Add the pam_namespace.so
module to the list of required modules in the /etc/pam.d/gdm file. Listing 5 shows
an example.
Listing 5. Configuring the Gnome Display Manager
#%PAM-1.0
auth required pam_env.so
auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
session optional pam_keyinit.so force revoke
session include system-auth
session required pam_loginuid.so
session optional pam_console.so
# Polyinstantiation:
session required pam_namespace.so
|
If you are using the X Display Manager (XDM) instead of GDM, configure the
/etc/pam.d/xdm file in the same way. Now both the graphical logins and the
command-line logins result in polyinstantiated /tmp and /var/tmp directories.
Finishing up: Allowing for errors
If PAM encounters an error when running the pam_namespace.so module, the login
session for the user trying to login will fail. Until you are sure that things are
operating as you intend, allow logins to continue in case of an error. To enable
the ignore_config_error option, add it to the end of
the line in each file in the /etc/pam.d directory where you added the
pam_namspace.so module.
For example, in the /etc/pam.d/login file, edit the line containing the
pam_namspace.so module as follows:
session required pam_namespace.so ignore_config_error
For a complete list of options, see the pam_namespace manual page. After a user
logs in, check the file /var/log/secure for errors. When you are satisfied that
your PAM configuration is correct, remove the ignore_config_error option.
Finishing up: Results
After you have modified and saved the configuration files, choose a non-root
user account to test and log out all instances of that user from the system. Log
in again and a new polyinstantiated /tmp and /var/tmp directory will be created
for that user. Listing 6 and Listing 7 show what this looks like on the system and
from the user's perspective. In this example, the username is robb.
Listing 6. Console session from the user's perspective
[robb@testbox tmp]$ cd /tmp
[robb@testbox tmp]$ touch foo
[robb@testbox tmp]$ ls
foo
|
Listing 7. Console session on the system as root
[root@testbox ~]# ls /tmp
tmp-inst
[root@testbox ~]# ls /tmp/tmp-inst/
robb
[root@testbox ~]# ls /tmp/tmp-inst/robb/
foo
|
Because of polyinstantiation, robb's /tmp directory is isolated in a separate
directory under /tmp/tmp-inst/, and robb cannot see the system /tmp directory or
any files within it.
Conclusion
While polyinstantiation will not prevent every type of attack, it is a useful
addition to your security toolkit that is straightforward to configure. Feel free
to experiment by polyinstantiating other directories such as /home. With the
ignore_config_error option, mistakes are not fatal, but
don't forget to remove that option after you have finished testing your
configuration.
Resources Learn
-
"Polyinstantiation of directories in an SE Linux system,"
by Russell Coker, describes the problems related to shared directories such as
/tmp and /var/tmp, as well as problems related to having multiple SELinux security
contexts used for accessing a single home directory.
-
"Applying
mount namespaces"
(developerWorks, September 2007) shows you how to build your own filesystem setup
without being constrained by the sysadmin-dictated structure; you'll discover some
practical applications for advanced Linux mounts features.
-
"Secure programmer: Minimizing privileges"
(developerWorks, May 2004) discusses how to minimize privileges by minimizing the
privileged modules, the privileges granted, and the time the privileges are
active.
-
"What's new in SELinux for Red Hat Enterprise Linux 5"
(Red Hat Magazine, May 2007) is an exhaustive overview of SELinux for RHEL5.
- This posting on
shared subtrees (LWN.net, November
2005) answers the question "A process wants to clone its own namespace, but still
wants to access the CD that got mounted recently" with a detailed list of
features, semantics, mount state descriptions, and implementation issues.
-
"SELinux from scratch"
(developerWorks, May 2006) shows you how to build an SELinux-ready Gentoo system.
-
"Role-based access control in SELinux"
(developerWorks, February 2008) shows you how to work with RBAC in SELinux, and
how the SELinux policy, kernel, and userspace work together to enforce the
RBAC and tie users to a type enforcement policy.
- The following resources can help you get a
handle on SELinux:
SELinux History and Project FAQ,
SELinux unofficial technical FAQ,
and
Configuring the SELinux Policy.
- Learn more about
Security-Enhanced Linux at the NSA Web
site.
- In the
developerWorks Linux zone,
find more resources for Linux developers, and scan our
most popular articles and
tutorials.
- See all
Linux tips
and
Linux tutorials
on developerWorks.
- Stay current with
developerWorks technical events and Webcasts.
Get products and technologies
Discuss
About the author | 
| | Robb Romans is a writer with the User Technologies group at IBM, and he focuses
on Linux, Cell Broadband Engine Architecture, and open source software. Before his
current work with the Information Development team, Robb was a developer working
on Linux security and embedded Linux. |
Rate this page
| |
