Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!recepsen.aa.msen.com!zib-berlin.de!irz401!uriah.heep!bonnie.heep!not-for-mail
From: j@bonnie.heep.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Restricting Telnet access
Date: 18 Aug 1995 11:17:34 +0200
Organization: Private U**x site, Dresden.
Lines: 28
Message-ID: <411lre$dv3@bonnie.tcd-dresden.de>
References: <40rt53$a6b@newsbf02.news.aol.com> <40ubkg$516@palmer.demon.co.uk>
Reply-To: joerg_wunsch@uriah.heep.sax.de
NNTP-Posting-Host: 192.109.108.139
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Gary Palmer <gary@palmer.demon.co.uk> wrote:
>There are several ``restricted shells'' available for FTP ...
>Please be careful - if you are going to allow them to edit their files with
>an editor, most editors support shell escapes, i.e. running commands from
>a shell forked from the editor, and every editor I know of will try running
>/bin/sh rather than the shell specified in /etc/passwd.
It should run ${SHELL} if this variable exists (and it does).
Anyway, i haven't been recommending these so-called `restricted'
shells since i believe they are rather opening more security holes
instead of plugging any, particularly for the not-so-experienced
(security-wise) admins. You have to be *very* carful to let the user
not even create (or modify) a single executable file (think of things
like Z-modem downloads, tar archives, cpio archives, the chmod command
and numerous other holes to get in), since this will immediately open
up a way to build their ``own private shell'', and be it for the only
reason to start a full-blown unrestricted shell consequently.
The only safe way for guest accounts is setting up a chroot'ed
environment. It's a lot of work, but can be considered safe.
--
cheers, J"org private: joerg_wunsch@uriah.heep.sax.de
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)