Using UUCP under a BBS system???

[Karl Denninger]

In article <237 at elrond.locus.com> sandy at locus.com (Sandy Zelkovitz) writes:
>In article <511182 at nstar.UUCP>, larry at nstar.UUCP (Larry Snyder) writes:
>> In article <2959 at murtoa.cs.mu.oz.au>, vortex at 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 at ddsw1.MCS.COM, <well-connected>!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"