How to Configure Restricted Shell to a Solaris User

rshThe restricted shell can be used to limit the ability of a user to change directories and execute commands. There are two versions of Restricted Shell included with Solaris: Those are:
/usr/bin/rksh   –  Restricted Korn Shell
/usr/lib/rsh      –  Restricted Bourne Shell, not a Remote Shell
Rest of the article discusses about rksh setup for a solaris user
 

What is the purpose of rksh ?

The Main purpose of Restricted Shell is  to set up users and execution environments with limited set of privileges compared to normal shell. The users with Restricted Shell  cannot perform following operations:
  • changing directory (cd command)
  • setting the value of SHELL, PATH or ENV (for rksh)
  • specifying path or command names containing /
  • redirecting output (>, >|, <>, and >>)
  • changing group (see newgrp(1) manpage).
The restrictions above are enforced after .profile and the ENV (for rksh) files are interpreted.
  • The user is limited to the home directory (user can’t use cd to change directories). If a user tries to change directory out of their home directory, they will receive:
rksh: cd: restricted
  • The user can use only the commands in the PATH set by the system administrator (user can’t change the PATH variable). If they try to run a command by specifying the full path, they will receive the following error:

rksh: /bin/command: restricted

  • This restriction is based on checking for a slash (/) in the path of the command to be executed. Thus, trying to execute /usr/bin/grep or ./bin/grep will fail to execute. This restriction, however, will not prevent specifying paths containing a slash (/) as a parameter to a command.

 

  • For example, if the vi or cat commands are included in the PATH, the user could view the contents of /etc/system (or any other file which they know the full path to) using the above mentioned commands. vi /etc/system or cat /etc/system will display contents of that file.

 

  • Restricted Shell does not restrict parameters passed to commands (so the slashes in /etc/system will be passed along without restriction). If the above setup is not restrictive enough, the a chrooted environment would have to be created. Chroot setup is beyond the scope of this document.

 

  • The user can’t redirect output with > or >>.

 

  • can only access their home directory (they will still be able to list files in other directories, if ls is provided)

 

  • can only run commands in the /rksh directory.

 How to Setup RKSH for a User?

Vi the /etc/passwd file and change the account’s shell field to /usr/bin/rksh (or to /usr/lib/rsh).
     e.g. dummy:x:78799:1::/export/home/dummy:/usr/bin/rksh
The PATH variable can be setup in either the /etc/profile or in the user’s $HOME/.profile. If the PATH is not set, then PATH will default to /usr/bin.   The inability to modify the PATH variable after interpretation of .profile can be used to restrict a user to a subset of commands, placing:
if [ “$0” = “rksh” ]
then
PATH=/rksh
export PATH
fi
in either /etc/profile or the user’s .profile will result in the user being able to execute commands only in the /rksh directory.
If the above script is placed in the user’s $HOME/.profile, then change .profile’s permissions to 755 and chown to root and the group to other (so that only administrator can modify this file).
Next, a /rksh directory needs be created. Commands can then be linked (or copied) from /usr/bin to this directory.
Example:
# mkdir /rksh
# cd /rksh
# ln -s /usr/bin/ls ls
# ls -l
lrwxrwxrwx     1 root         other                 13 Nov 15 11:46 ls -> /usr/bin/ls
Note : Be aware that the restrictions mentioned above will be active as soon as the restricted shell has been started. Certain daemons may want to fork additional “helper applications” which may fail here. One example of such a daemon would be sshd and the use of special subsystems, d.g. sftp will use /usr/lib/ssh/sftp-server (as defined in /etc/ssh/sshd_config) and this start will fail if the target user has a restricted shell.
Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us