[TriLUG] Using a restricted shell for limited access to a remote system

[Mike Johnson]

jonc wrote:
> We were just play around in IRC and I ran across this nice link. Sharing
> is fundamental to OpenSources, so here it is...

Restricted shells are not a good way of solving the problem of what 
users can do.  Do some google searches on 'rbash security' and you'll 
see what I mean.  Take a look at exactly what you want the user to be 
able to do, and attack that problem.  Only want remote file access? 
There are programs you can use as the user's shell to only invoke sftp. 
  Maybe there is a better way, say webdav over ssl, as an example. 
Maybe shared IMAP folders.

Anyways, think seriously about what you want to allow a user.  A 
restricted shell like rsh or rbash is probably not what you want to do.

Mike

 From an old 2002 article:
http://www.securityfocus.com/infocus/1575

<quote>
First, let’s look at the restricted shell. There are simply too many 
ways things can go wrong: modifying environment variables (such as 
EDITOR, VISUAL, and others unlocked by rbash), starting applications 
with shell escapes, changing user's shell, simply running the downloaded 
shell binary and numerous other methods can let the bird fly out of the 
cage.

A well-written menu shell is a significant improvement. The "breaking 
focus" is now on the applications that are being launched from the menu 
shell. The problem lies in the fact that many UNIX console applications 
have a shell escape. Examples include pine (Ctrl-Z), vi (:!'bash'), ftp 
(!), telnet (!), emacs (M-x shell), gdb (shell) and many others. 
(figures in brackets are the commands that invoke a shell.) It is 
interesting to note that some of the applications will spawn a new copy 
of restricted shell and some will use regular /bin/sh. It is worth 
noting that vi (vim) has a special restricted mode with no shell escape 
feature. In can be invoked by calling rvim in a manner similar to bash 
and rbash. To make applications resistant to such an attack, one has to 
manually remove the shell escapes from the source code, which is 
probably too time-consuming for most uses.

Even if the launched application does not provide for shell escape, one 
can crash the application using the overflow shellcode (/bin/sh) 
typically used for overflowing SUID binaries and gaining root. If 
shellcode is used for crashing the application or the menu-based shell 
itself, the clean copy of /bin/sh will be launched (provided that one 
exists, which might not be the case in chroot environment).
</quote>