Xref: utzoo comp.unix.xenix:10265 comp.unix.i386:3128 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ficc!morrison From: morrison@ficc.uu.net (Brad Morrison) Newsgroups: comp.unix.xenix,comp.unix.i386 Subject: Re: Using UUCP under a BBS system??? Message-ID: Date: 22 Feb 90 14:46:11 GMT References: <2959@murtoa.cs.mu.oz.au> <511182@nstar.UUCP> <237@elrond.locus.com> <1990Feb13.214855.4265@ddsw1.MCS.COM> <.OV1S=Axds13@ficc.uu.net> <1990Feb20.202554.19826@ddsw1.MCS.COM> Reply-To: morrison@ficc.uu.net (Brad Morrison) Organization: Ferranti International Controls Corp. (NYSEG SCADA) Lines: 23 >>In article <1990Feb13.214855.4265@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) posed the problem of the shell escapes from things, especially vi. Then, in article <.OV1S=Axds13@ficc.uu.net>, I proposed a wrapper around the real shell to exclude restricted users. In article <1990Feb20.202554.19826@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >But what if the user finds out the real shell's name? Touche; I hadn't thought about this...Conor P. Cahill also pointed this out, and I'm sure that more people have thought of it. >Security by obscurity is not security; it's hiding things. And hidden >things aren't locked, they're simply hidden. Of course, since they are only >hidden, they can also be found. So hiding it is out. I think that the problem isn't hacking the shell, though; of all the tools mentioned as permitting shell escapes, the only real offender is 'vi'. All of the others are bad only because they can chain to vi and get a configurable shell escape via ":set shell=/bin/sh". But you don't want to exclude 'vi', I don't think. What about replacing it, instead of replacing the shell? -- Brad Morrison (713) 274-5449 | "OK. Come back tomorrow. Ferranti International Controls Corporation | Bring two apples and uunet!ficc!morrison morrison@ficc.uu.net | a hammer."