MAN page from RedHat EL 7 rssh-2.3.3-2.el7.rf.x86_64.rpm

RSSH

Section: Derek D. Martin (1)
Updated: 1 Aug 2010
Index

NAME

rssh - restricted secure shell allowing only scp and/or sftp

SYNOPSIS

rssh [ options... ] [ ... ]
rssh -v

DESCRIPTION

rsshis a restricted shell for providing limited access to a host via ssh(1), allowing a user whose shell is configured torsshto use one or more of the command(s) scp(1), sftp(1)cvs(1), rdist(1), and rsync(1), and onlythose commands. It is intended primarily to work with OpenSSH (seehttp://www.openssh.com), but may work with other implementations.The system administrator should install the shell on the restricted system.Then the password file entry of any user for whom it is desireable to providerestricted access should be edited, such that their shell is rssh. Forexample:

: luser:x:666:666::/home/luser:/usr/bin/rssh

If invoked with the -v option,rsshwill report its version, and exit. All other arguments to rsshare those specified by the remote ssh(1) client, and aren't of muchconcern to the average user. The arguments provided must be what a shell onthe remote end would receive in order to pass control to scp(1),sftp(1), etc. If rsshreceives arguments which do not conform, it will emit an error message and exit.If the program the user is trying to run is not allowed, or contains syntaxwhich will try to execute a shell command (such as a command substitution), itwill also emit an error and exit.rsshhas a configuration file, rssh.conf(5), which allows some of thebehavior of rsshto be customized. See that man page for details.

SECURITY NOTES

Read this section with exceptional care, or you may put your system at risk!

Using rssh With CVS

If you are using rssh to allow CVS access, it should be noted that it isnot possible to prevent a user who is very familiar with CVS from bypassingrssh and getting a shell, unless the user does not have write access inthe repository. Obviously, the user must have write access to the repositoryin order to update it, which allows them to upload arbitrary programs into therepository. CVS provides several mechanisms for executing such arbitraryprograms... The only reasonably safe way to use rssh with CVS is to usethe chroot jail facilities to place the CVS repository within a chroot jail.Please see below and all relevant documentation for details of how to set upchroot jails. Note that users will still be able to get shell accesswithin the jail; the only protection which is provided is that they can notescape the jail. I have been pursuaded to retain support for CVS because thisprotection is better than no protection. You have been warned. Use CVS at your own risk.

Potential root Compromise With Old Versions

Before rssh 2.3.0, if a regular user had shell access to a machine wherersshwas installed, a root compromise was possible due to rssh_chroot_helperallowing a user to arbitrarily chroot(2) to anywhere on the filesystem.It is possible to mitigate this attack against affected versions of rsshusing strict access controls to files, by making sure that the user can notwrite to any file on the same partition as system executables, and that anypartition where they can write files does not allow execution of SUIDprograms. As of rssh 2.3.0, this attack has been prevented bypreventing arbitrary chroot(), if your jail is set up securely. Inparticular, make sure that regular users can not write to directories insidethe jail which contain the copied binaries. That should be obvious, but itneeds to be said. Though it should not be strictly necessary, to furtherprotect your system from possible compromise, it is also advisable to followthe section below, entitled "Safeguards Against Bypassing rssh".

Safeguards Against Bypassing rssh

rsshis designed to interact with several other programs. Even if rssh iscompletely bug-free, changes in those other programs could possibly result inmethods to circumvent the protection thatrsshis intended to provide. It is important for you, the system administrator,to stay current on the services you make available with rssh, to be sure thatthese commands do not provide mechanisms to allow the user to run arbitrarycommands. Also, while the goal of every release is to be bug free, no oneis perfect... There may be undiscovered bugs in rssh which might allow a user to circumvent it.You can protect your system from those who would take advantage of suchweaknesses. This is not required for rssh to work properly, but it is areally good idea. There are six basic steps:

1.: protect all non-administrator accounts with rssh (i.e. no regular user should have shell access to the server)
2.: place your users in a chroot jail
3.: limit the binaries which live in the jail to the absolute minimum required
4.: mount their home filesystem with the noexec/nosuid option (i.e. useseparate partitions in the jail for user home directories and all other files,if possible/reasonable)
5.: create a group for rssh users, and limit executable access to the binaries tousers in that group.
6.: use standard file permissions carefully and appropriately

If possible, make sure that no regular user has any kind of shell access tothe system other than through rssh. Otherwise, users with shell accesscould potentially exploit undiscovered bugs in rssh_chroot_helper to gain root access to the server.rsshgives the system administrator the ability to place the users in a chrootjail. See details in the man page forrssh.confand in the fileCHROOTwhich is distributed with the source code. If you want to ensure users cannot run arbitrary programs, use a chroot jail, and be sure not to put anyprograms other than what are absolutely necessary to provide the service youare trying to provide. This prevents them from running standard systemcommands.Then, make sure the user's files inside the jail are on a seperate filesystemfrom your system's executables. If possible in your environment, make sureyou mount this filesystem using thenoexec and nosuidoptions, if your operating system provides them. This prevents the users frombeing able to execute programs which they have uploaded to the target machine(e.g. using scp) which might otherwise be executable, and prevents SUIDprograms from respecting the SUID bits. Note that these options necessitatethe users' files are on separate partitions from the binaries and librariesthat live in the jail. Therefore you will need at least 2 partitions for yourjail to do this properly (one for the system binaries in the jail, the otherfor the user directories).Additionally, create a group, for example "rsshuser", for rssh users. Put allyour users who will be restricted by rssh in that group. Set the ownershipand permissions on rssh and rssh_chroot_helper so that only those users canexecute them. The following commands should illustrate:

: # groupadd rsshuser
# chown root:rsshuser rssh rssh_chroot_helper
# chmod 550 rssh
# chmod 4550 rssh_chroot_helper

Lastly, use standard Unix/POSIX file permissions to ensure theycan not access files they should not be able to within the chroot jail.

Command Line Parser

As of rsshversion 2.2.3, the program must parse out the complete command line to avoidcommand line options which cause the execution of arbitrary programs (andhence bypass the security of rssh). In order to keep the program sourcecode sane, the parser is a little over-zealous about matching command lineoptions. In practice, this probably will not be an issue, but in theory it ispossible. If you run into a problem wherersshrefuses to run, claiming to be rejecting insecure command line options whichwere not specified, try changing your command line such that all shortoptions are specified as single-letter option flags (e.g. -e -p instead of-ep) and make sure you separate arguments from their respective options by aspace (e.g. -p 123 instead of -p123). In virtually all cases, this shouldsolve the problem. Admittedly, an exhaustive search was not performed, but noproblematical cases were found which were likely to be common.The alternative would have been to include a complete command-line parser forrcp, rdist, and rsync; this was way out of the scope of this project. Inpractice, the existing parser should suffice. If, however, you find caseswhere it does not, please post details to the rssh mailing list. Detailsabout how to post to the mailing list can be found at the rssh homepage.

OpenSSH Versions and Bypassing rssh

Prior to OpenSSH 3.5, sshd(8) will generally attempt to parse files inthe user's home directory, and may also try to run a start-up script from theuser's$HOME/.sshdirectory. rssh does not make use of the user's environment in any way. The relevant commandis executed by calling execv(3) with the full path to the command, asspecified at compile time. It does not depend upon the user's PATH variable,or on any other environment variable.There are, however, several problems that can arise. This is due entirely tothe way the OpenSSH Project's sshd works, and is in no way the fault ofrssh. For example, one problem which might exist is that, according tothe sshd(8) man page from at least some releases of OpenSSH, thecommands listed in the$HOME/.ssh/rcfile are executed with/bin/shinstead of the user's defined shell. This appears not to be the case on thesystems the author had available to test on; commands were executed using theuser's configured shell (rssh), which did not allow the execution.However if it is true on your system, then a malicious user may be able tocircumventrsshby uploading a file to$HOME/.ssh/rcwhich will be executed by /bin/shon that system. If any releases (of OpenSSH) are, in fact, vulnerable to thisproblem, then it is very likely that they are only old, outdated versions. Solong as you are running a recent version of OpenSSH, this should not be aproblem as far as I can tell.If your sshd isvulnerable to this attack, there is a workaround for this problem, though itis pretty restrictive.The user's home directory absolutely must not be writable by the user.If it is, the user can use sftp to remove the directory or rename it, and thencreate a new one, and fill it up with whatever environment files they like. Forproviding file uploads, this means a user-writable directory must be created forthem, and they must be made aware of their inability to write into their homedirectory other than in this location.A second problem is that after authenticating the user, sshd also reads$HOME/.ssh/environmentto allow the user to set variables in their environment. This allows the userto completely circumvent rssh by clever manipulation of such environment variables asLD_LIBRARY_PATH or LD_PRELOADto link the rssh binary against arbitrary shared libraries. In order toprevent this from being a problem, as of version 0.9.3, by defaultrsshis now compiled statically. The restrictive work-around mentioned above willalso defeat this sort of attack.As of OpenSSH 3.5, sshdnow supports the optionPermitUserEnvironmentwhich is set to "no" by default. This option allows restricted shells likersshto function properly without requiring them to be linked statically. As ofrsshversion 1.0.1, the configure script should detect that OpenSSH 3.5 is present,and disable the default of static compilation.

BUGS

None. =8^)

A Note About Getting Help

If you are having trouble gettingrsshworking, or you think you've found a bug, please use the mailing list, anddo not e-mail medirectly. You must sign up for the list in order to post. Information about how to signup is available on the rssh homepage. If you mail me directly with questions,I will almost certainly ignore you, or at the very least ask you to repostyour question on the mailing list. Please also feel free to provide feedbackabout rssh on the mailing list, whether positive or negative (especiallynegative).

Security Problems

The only exception to the above is if you believe you have found a securityproblem with rssh. If that is the case, then please do contact meprivately. If you are unable to find my direct contact info, post a message onthe mailing list requesting that I contact you about a potential securityproblem. Security problems should be dealt with privately, so that the threatcan be properly assessed, and so as not to needlessly endanger theinstallations of rssh in production environments. I take securityproblems seriously, and will work to resolve them as quickly as possible.

N.B.:

Before you e-mail me (or the mailing list) with questions, be sure to THOROUGHLY read all of the following files: README, INSTALL, CHROOT, SECURITY. All ofthese files are distributed with the rssh source code, as well as all binarypackages of rssh. If you downloaded a binary package, these filesshould be located wherever your distribution keeps its documentation files(usually /usr/share/doc/rssh-version/ or something similar). Also THOROUGHLY read the man pages for rssh(1), and rssh.conf(5). Finally, if youare still having problems, read the FAQ athttp://www.pizzashack.org/rssh/faq.shtml. If it is clear to me that you havenot read these documents, I will ignore you. In most cases, these documentswill already have everything you need to get rssh working, and I won't be ableto explain it any better on a mailing list than I did in those documents...

Index

Using rssh With CVS
Potential root Compromise With Old Versions
Safeguards Against Bypassing rssh
Command Line Parser
OpenSSH Versions and Bypassing rssh

BUGS

A Note About Getting Help
Security Problems
N.B.:

SEE ALSO

This document was created byman2html,using the manual pages.