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>
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
