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. ;-)