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

[jonc]

On Thu, 2006-03-02 at 15:58, Mike Johnson wrote:
> 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>

Yep. That article is even quoted in the above link.  Still it's handy
stuff to be able to do if you have some limited items you want to allow
some local users to have access to.

I've done similar things by using a chroot - which I think is much safer
but also much harder to setup.

Jon