Xref: utzoo comp.unix.xenix:10081 comp.unix.i386:2943 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.unix.xenix,comp.unix.i386 Subject: Re: Using UUCP under a BBS system??? Summary: The problem with "doors" is convenience and security. Message-ID: <1990Feb13.214855.4265@ddsw1.MCS.COM> Date: 13 Feb 90 21:48:55 GMT References: <2959@murtoa.cs.mu.oz.au> <511182@nstar.UUCP> <237@elrond.locus.com> Reply-To: karl@mcs.MCS.COM (Karl Denninger) Organization: Macro Computer Solutions, Inc. - Mundelein, IL Lines: 124 In article <237@elrond.locus.com> sandy@locus.com (Sandy Zelkovitz) writes: >In article <511182@nstar.UUCP>, larry@nstar.UUCP (Larry Snyder) writes: >> In article <2959@murtoa.cs.mu.oz.au>, vortex@cs.mu.oz.au (Mark Gregson) writes: >> > I don't suppose anyone out there would know if >> > there is a BBS system for Xenix that will allow >> > users to use the UUCP mail facility?? >> >> AKCS will do just what you are looking for plus a whole lot more. >> >> > I have been told that XBBS will do this, is this true or >> > false?? I want users to be able to send and receive UUCP >> > mail whilst logged into the BBS and not have to give out >> > shell accounts for this facility. ^^^^^^^^^^^^^^ Bingo. You hit the problem on the head. Those pesky shell accounts :-) >> The last time I looked at XBBS, it would only allow the spawning of >> external news software - and one would have to set up an account for >> your users to access the mailer - which would leave the system open >> for security problems. AKCS takes a cleaner approach with the mail >> front end built into the main package. >> >Larry, > >Unfortunately, you completely forgot about the Additional Features Section >of XBBS. As you know, the System Administrator can select any external >program and/or shell script as a feature for his users. Also, this you >may not know, XBBS has the capability of having MANY special SIG sections. >Each section, also has its own Additional Features section. "Doors" have a few giant drawbacks (although we provide them in AKCS too). They require, at least under Unix: 1) Separate accounts in order to know who's doing what, or a method that is mutually understood by the CALLED PROGRAM to identify who it is that is calling the program (we provide this in the form of passed arguments). 2) Ungodly amounts of concern over security; "standard" Unix utilities (mail included) simply WILL NOT DO. This goes for text editors, mailers, and nearly everything else provided in the standard Unix distribution. The second is the killer. Let's say you don't want people getting to the shell, for whatever reason. Here's a partial list of what you can't let them execute (even internally as a pager or mailer): vi and friends (ex, view, etc) more mail pg most other editors anything with a shell escape, or anything which can chain to an editor Why? Well, you'd think that "SHELL=/bin/true;export SHELL" would protect you from the vi ":!". It won't. Try ":set shell ...." sometime inside vi, then a ":!...." and you'll be suitably shocked. The same problem exists with "more"; it can chain to "vi", and from there.... There is no way to protect from this without source code to those utilities. Even if you "rsh" people they can screw you using this method. Every scheme we've tried (other than removing the shell from the system!) I've been able to penetrate within a few minutes; "rsh" environments included. Only a "chroot" environment provides reasonable safety. For mailers you have a bigger problem. You have to do your own mail program, and a delivery agent as well! Why? Because most of them can change "folders" (ie: ELM; this is deadly when one user id owns all the mailboxes!), and the rest want to see your mail in /usr/mail/xxxx or /usr/spool/mail/xxxx (depending on operating system). Now how, may I ask, do you manage this if you don't have a shell account? (not to mention delivering the mail to the user's mailbox itself, which rmail won't normally do without a passwd entry...) Chrooting the user's area is a real problem if you want to do outside mail as well.... Doors can be useful. We have a multiuser real-time game called "cosmos" which is executable through the AKCS external program functions. It maintains security (there isn't a shell escape in it; if you are stupid enough to sit around you'll be dead before you could use one :-). "chat", which I have posted to alt.sources a few times (it's shareware; essentially an online "CB") does the same thing. >For the readers of this message that are not familiar with XBBS, the Additional >features section is similar to the "doors" function within may MSDOS bbs >programs. The SysAdmin can select to have a particular selected program to >be either interactive or non-interactive. If you wish to have your users >run the mail program, so be it! All you have to do is select that program >to be interactive and off it goes. I would, however, use a mail program >which does not have a shell escape. This will guarantee system security. Of course, this also means you have to allow the user a shell login. Otherwise how do you get DELIVERY of the mail to their user mailbox? Once you've given out a shell login, you may as well give out shell access. MSDOS people have it >somewhat< easier. DOS isn't designed to be as easily maneuvered into doing "open" things as Unix is. Even so, I have heard plenty of tales of woe from MSDOS BBS owners who >had< a door program, had it "broken out of", and ended up with someone uploading (or executing) Disk Manager and formatting their fixed disk! Ouch! >If you really want certain users to have "mail" capabilities, I would set >up a special SIG for this function. And how about offsite mail? How do you handle that? SIGs are fine, with private messages, but they won't interchange with anyone else. From AKCS I can mail to anywhere that my machine can reach, and any Internet or UUCP site can mail me -- without hassles. Just use the Reply-To: or From: address; it will get there. For those who will flame, no, I'm not poking at Sandy. I'm trying to find out if there really is an easier way to do it than AKCS does. We looked at this long and hard, and got more than one surprise (ie: the "set shell" thing above) before we settled on providing the support internally and writing a driver for smail3 to handle delivery. There really appeared to be no easier way to do the job correctly and in a way that wouldn't compromise security. No, AKCS isn't free; it's commercialware. Yes, I wrote it. Of course I'm biased. -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"