Using UUCP under a BBS system???

[Leslie Mikesell]

In article <1990Feb13.214855.4265 at ddsw1.MCS.COM> karl at mcs.MCS.COM (Karl Denninger) writes:
>"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.
[...]
>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.

Why not provide separate accounts with the BBS program as the login shell?
This suffices for point (1).
For point (2), if you want to let them execute something that allows shell
escapes, just fork off a child that chroot()'s into a suitable padded
environment before execing the program.  

>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...) 
These are good reasons to use normal accounts (which doesn't imply shell
access if the login shell is the BBS program...).

>Chrooting the user's area is a real problem if you want to do outside mail
>as well....

Shouldn't be all that difficult if you mv the system mailbox into the chroot
area before putting the user there and provide suitable mail/rmail programs
that will leave outgoing messages queued where the parent program can find
them as you exit back to the bbs.  Or provide some IPC connection to a
server program that doesn't chroot() but does check requests carefully
(pipes on open fd's come to mind).

>[XBBS stuff deleted...]
>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.

Not at all.  You can provide a user id for mail but use an impossible-to-
match entry in the encrypted password field, or just specify the bbs as
their login shell.  All mail cares about is a match in the login field, and
of course you want unique id numbers for file ownership purposes.

>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!

That's supposed to be better than unix???

Les Mikesell
  les at chinet.chi.il.us