SecFile & Restricted Shell

Securing the Restricted Shell

By Chris Wong

In this column we will look at important configuration and patch information for securing restricted shell users and why these are important. But first, let’s quickly review the /etc/default/security file. A few years back HP implemented the /etc/default/security file (man 4 security) on HP-UX. This file is used to configure additional security features such as those listed in the following table:

Description	Keyword
Abort the login if home directory is missing	ABORT_LOGIN_ON_MISSING_HOMEDIR
Change the minimum password length	MIN_PASSWORD_LENGTH
Only allow root to login when the /etc/nologin file exists	NOLOGIN
Limit the number of concurrent sessions for non-root users (su excluded)	NUMBER_OF_LOGINS_ALLOWED
History of previous passwords	PASSWORD_HISTORY_DEPTH
Allow “su” to the root user only if you belong to a specific group	SU_ROOT_GROUP
The default PATH to be set when using the “su” command	SU_DEFAULT_PATH
Force the user to specify a minimum number of a specific type of characters when setting their password (see PHCO_26089)	PASSWORD_MIN_UPPER_CASE_CHARS PASSWORD_MIN_LOWER_CASE_CHARS PASSWORD_MIN_DIGIT_CHARS PASSWORD_MIN_SPECIAL_CHARS
Forces the export of environment variables associated with LD_LIBRARY_PATH, SHLIB_PATH, and/or LD_PRELOAD to a child process of a “su”. (see PHCO_27781)	SU_KEEP_ENV_VARS

Effective with patches (PHCO_27721 for HP-UX 11.0 or PHCO_27694 for HP-UX 11.11) is a new parameter for the /etc/default/security file that is specifically for restricted shell users. For a time in HP-UX, the default behavior would allow a restricted shell user to bypass being in a restricted shell. This was accomplished by exploiting an option that is available with the login command.

There are only a few settings that force a restricted shell user to stay in their restricted shell. If any of the steps to create a restricted user are in error or are later modified, the restricted user could gain access beyond what you are expecting. Since you have placed this user in a restricted shell, common sense says this is not a user you want snooping around your system. In order to understand the reason for these new settings, let’s review the required steps for a restricted shell user:

1). The login shell listed in /etc/passwd is /usr/bin/rsh

2). The user’s home directory must have permissions of 555

3). Create a bin directory in the user’s home directory, also with permissions of 555

4). The user’s .profile will have only one entry:

export PATH=/home/guest/bin

5). The permissions on the user’s .profile will be 444 and owned by root/sys

6). Copy only the programs needed by the user to their bin directory

7). Add the user to the /etc/ftpd/ftpusers file

8). Restrict the user from other services using other configurable access control files

The reason for these steps:

1). The user is not allowed to create their own files/directories

2). The user is not allowed to “cd” out of their own home directory

3). The user may only execute commands found in their bin directory or built into the restricted shell

4). The user may not execute command names that contain “/”

5). The user may not redirect output with >, >>, or 2>

These steps greatly reduce the ability of this user to do damage to the system. Setting up restricted shell users is a great way to limit access to the system for specific users. However, be careful, just the simplest mistake and this user will no longer be in a truly restricted shell. For example, a typo made in the .profile or changes made to permissions will grant this user greater access.

Even with a properly configured system, it may be possible for the user to get out of their restricted shell. How is this possible? Well, take a look at the required eight steps. In what way could any of these be bypassed? The easiest is the setting of the PATH variable found in the .profile. In the past, default HP-UX allowed you to use additional parameters with the login command that are much too permissive. For example, let’s look at the old default behavior in a restricted shell account named nancy:

$ pwd

/home/nancy

$ cd /

rsh: cd: The operation is not allowed in a restricted shell.

$ more /etc/passwd

rsh: more: not found.

The pwd command works as this is part of the shell (it is not listed in bin). The change directory command does not function and the more command does not work since it is not in the user’s PATH.

What happens when we changed our login information to include one of the four possible passable parameters (MAIL, HOME, ENV, TERM):

Password:

$ pwd

/home/guest

$ cd /

rsh: cd: The operation is not allowed in a restricted shell.

$ more /etc/passwd

root:/aVq3hN0TEiY.:0:3::/:/sbin/sh

daemon:*:1:5::/:/sbin/sh

bin:*:2:2::/usr/bin:/sbin/sh

sys:*:3:3::/:

Yikes! I don’t think that is what you attended this restricted shell user to be able to do. Why can they do that? Because they set the HOME variable at the login prompt to be a directory that does not have a .profile. This caused their PATH variable to be set incorrectly. Since the PATH variable is wrong, the user is now able to execute commands found in their new non-restrictive PATH.

After installing patch PHCO_27694 (on 11.11) the same command would give the correct output:

Password:

$ more /etc/passwd

rsh: more: not found.

By default in HP-UX (on a properly patched system) only the TERM and DISPLAY parameters will be accepted with the login command when the user’s default shell is the restricted shell. However, the following settings are also now available in the /etc/default/security file (after PHC0_27694):

RSH_SECURITY value	Behavior Description
0	Will revert to the old (unpatched) permissive behavior
1	It is possible to ease the restrictions and allow the setting of any environment variables which are not known to be potentially risky. (From HP patch documentation)
2	The default (with patches) behavior

It is not recommended to change the now correct HP-UX behavior by setting the RSH_SECURITY setting to 0. The setting of 1 is interesting. For example:

Password:

$ echo $MYOWNVAR

newfdawg

I’m not sure how it determines what environment variables are risky or not, but unless you have a very unique reason to need this, stick with the setting of 2.

Note: Patch information is from December 2002. Please check http://itrc.hp.com for current patch information. The “new” default HP-UX restricted shell behavior was made available in previous patches.

Chris Wong is a technical consultant and trainer for Cerius Technology Group, Inc. in Bellevue, WA. She is the author of the HP Press book “HP-UX 11i Security”. http://newfdawg.com

All Rights Reserved, Copyright 2000 - 2002, TechTarget
SearchHP.com is a search service provided by TechTarget and is completely independent of and not affiliated with Hewlett-Packard Company.