Using UUCP under a BBS system???

[Karl Denninger]

In article <1990Feb15.072929.22712 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
>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).

Does it?  What if you don't want the hassle (which is non-zero) for any one
of several reasons, or you just don't want to assign user logins and
passwords at the Unix level?  There may be several reasons for this; some
political (ie: you don't have "root" access on the machine) and some technical.

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

That works, but is a pain in the neck.  It requires duplicating programs 
(note that ln'ing programs is VERY dangerous for chrooted areas, as if a 
"bad guy" changes the linked image, he changes the original too!)  What
do you do if you don't have the disk space to reasonably provide that
"chrooted" area for use?

We used to run with a "chroot()"ed area.  So did Chinet, if I remember
correctly.  Neither of us do now.  Hmmmm.... I don't know why Chinet stopped
doing it, but I do know that disk consumption was part of the reason we
quit.

Also, chroot() requires root privileges to execute.  That's an entirely 
different can of worms; one that many people would rather not open.

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

Or a good reason to have the system manage the entire thing, providing a
mail reader and sender, and forget about the potential hassles of "normal 
accounts".

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

Now you have to write a mail delivery program.  

I guess this is ok if you want to hack on things for a few
(days/weeks/months).  It's not so hot if you want to take something out of
the package, install and use it!

Not all people who want to run systems for the public also want to take 2-3
weeks to get things set up and stabilized, not to mention tested.  

Mail delivery isn't exactly trivial either.  You would think it would be,
but it's not -- since not all user agents output mail in a RFC-compatible
format (or are missing important headers, such as mail(1)).  We ran into 
this originally when we were working on AKCS, which is why we now recommend 
that people go to smail3 (most vendor's mail packages have at least one or 
two warts :-)

>>[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.

The "of course" can be rather, uh, interesting when you run into the 32k
limit on user id numbers.  Now you get to compact the /etc/passwd file, or
do something automatically to do the same.

One of the nice things about getting the bbs user information out of
/etc/passwd is that you >know< at a glance that anyone who has a password
entry is a shell user and not a "bbs" user.  Very useful indeed when you're
trying to keep track of what's going on!

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

I didn't say "better", I said less likely to give you a "gotcha" without
your knowing about it.  Every MSDOS user knows what FORMAT C: does.  Not too
many mainstream Unix buyers know what dd can do to /dev/dsk/0s0!

Too many vendors do really foolish (and poor) things like shipping their 
Unices so they install with writable roots, writable device files (ouch!) 
and lots of other "fun" things.  SCO and 386/ix aren't immune to this; both 
of those required some work before they were secure enough to let people at 
the shell without too much worry.  We've closed the obvious holes... but it
wasn't that way when freshly installed.

Joe Average UNIX installer (who is more and more the typical Unix buyer!)
doesn't know all these things, isn't going to take the time to learn them,
and WILL get hurt.  Saying "well, you should know" isn't good enough if we
expect Unix to catch on as a "mainstream" operating system.  Trying to get
the vendors to clean up their acts (and installations) isn't easy (if even
possible) either.  So what do you do?

You make your products as bulletproof as possible.  You allow the shell user,
or the person with login access (but a shell of your product) to use the 
package -- without hassle.  You also provide a nice secure path in which
doesn't require that the user be able to do these things if you can.

Choice is the name of the game; that's the Unix way, isn't it? :-) 

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