vortex@cs.mu.oz.au (Mark Gregson) (02/10/90)
Hi, 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?? 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. All help greatly appreciated.... PS: Thanks to those persons that replied to my previous messages regarding BBS systems. Regards, Mark Gregson
jbayer@ispi.UUCP (Jonathan Bayer) (02/10/90)
vortex@cs.mu.oz.au (Mark Gregson) writes: > Hi, > 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?? > 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. XBBS will allow you to do this, up to a point. You can allow your users access to the shell, at which point they have access to the mail facility. However, if you want them to be able to receive mail you will have to either give them login accounts, or start hacking with the mailer. JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204
larry@nstar.UUCP (Larry Snyder) (02/11/90)
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. 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. Call into my system (running AKCS) -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry 4 inbound dialup high speed line public access system
jpp@tygra.UUCP (John Palmer) (02/11/90)
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?? } The CAT-TALK Conferencing System now operates under Xenix and is available at a toll free number for $20 a month. Thats cheap considering that you get unlimited session time. We carry Usenet news and people can send uucp mail (or internet mail). See my signature for instructions on how to sign up for access. You get a free 20 minute session to try out the system. Starting sometime next week, we will be carrying ClariNet newsgroups. These are professionally written "E-MAGAZINE" type groups. -- = CAT-TALK Conferencing Network, Prototype Computer Conferencing System = - 1-800-825-3069, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. E-Mail Address: jpp%tygra.UUCP@sharkey.cc.umich.edu = - <<<Redistribution to GEnie PROHIBITED!!!>>>> -
les@chinet.chi.il.us (Leslie Mikesell) (02/12/90)
In article <511182@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >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. Can you explain why having an account per user would cause any security problem? I can understand wanting a mail front-end built into a bbs for convenience but I don't see any advantage for security. Les Mikesell les@chinet.chi.il.us
karl@ddsw1.MCS.COM (Karl Denninger) (02/12/90)
In article <2959@murtoa.cs.mu.oz.au> vortex@cs.mu.oz.au (Mark Gregson) writes: > > Hi, > 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?? > > 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. > > All help greatly appreciated.... > > PS: Thanks to those persons that replied to my previous > messages regarding BBS systems. AKCS can handle this; it works best if you also install SMAIL3 (which is no-charge, seeing as it's freely redistributable). AKCS is a commercial product. Call or write for more information on it. It's available at a quite-reasonable price. In addition to being able to handle the user side of things, it will also gateway Usenet newsgroups if you want and/or network with other AKCS systems. -- Karl Denninger (karl@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"
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/12/90)
In article <2959@murtoa.cs.mu.oz.au> vortex@cs.mu.oz.au (Mark Gregson) writes: | | Hi, | 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?? Citadel does, I think XBBS does, too. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
sandy@locus.com (Sandy Zelkovitz) (02/12/90)
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. > > 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. 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. If you really want certain users to have "mail" capabilities, I would set up a special SIG for this function. Sanford <sandy> Zelkovitz XBBS 714-821-9671 (data) 714-821-9670 (voice) P.S. XBBS is FREE ( source code included )
larry@nstar.UUCP (Larry Snyder) (02/13/90)
> Can you explain why having an account per user would cause any security > problem? I can understand wanting a mail front-end built into a bbs > for convenience but I don't see any advantage for security. Les - I just feel better keeping strangers (unknown users) out of my shell and restricted to the BBS (AKCS in this case) which is very secure. To reply to your original comments - yes - shell access can be made secure. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry 4 inbound dialup high speed line public access system
david@csource.oz.au (David Nugent) (02/14/90)
> From: sandy@locus.com (Sandy Zelkovitz) > Date: 12 Feb 90 15:26:43 GMT > Organization: Locus Computing Corp., Los Angeles > Message-ID: <237@elrond.locus.com> > > 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. Good to see you're still developing it. Last version I got was 5.1 (from memory) ... what version is current? Is it available PEP? david -- UUCP: ...!munnari!csource!david INTERNET: david@csource.oz.au Via FidoNet 3:632/348, Central Source ICBS, Melbourne, Australia
karl@ddsw1.MCS.COM (Karl Denninger) (02/14/90)
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, <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"
peter@ficc.uu.net (Peter da Silva) (02/15/90)
I don't understand this aversion to giving BBS users UNIX ids. You can
make the BBS program their login shell and have all the advantages of
a secure environment, and you won't have to do any special gyrations
to get mail working.
Sure, there are a handful of interactive programs you have to hack, but
there are more free mailers/editors/pagers that you can hack the way you
like than you can shake a stick at.
Really, what's the problem?
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
v "Have you hugged your wolf today?" `-_-'les@chinet.chi.il.us (Leslie Mikesell) (02/15/90)
In article <1990Feb13.214855.4265@ddsw1.MCS.COM> karl@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@chinet.chi.il.us
kmcvay@oneb.UUCP (Ken McVay) (02/16/90)
In article <237@elrond.locus.com>, sandy@locus.com (Sandy Zelkovitz) writes: > > 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 As a novice to Xenix, Sandy, I can tell you that I avoid offering many features via bbs shells, simply because I do not know how to protect the system from abuse, should a user know how to shell to the o/s from, say, vnews or vi. For that reason, I continue to look for a bbs that will permit me to offer my users access to uucp mail and selected newsgroups, while eliminating unwanted shells. I know AKCS will handle this, but I keep hoping something less expensive will come along (I've been spoiled by Opus/Fido/FrontDoor/SEAdog quality - the dos world abounds with superb packages at reasonable prices) so that I can take full advantage of the power of this system. Consider - at the moment, my Xenix system collects the mail and delivers it to my FrontDoor- Opus (read: MS-DOS) system, where folks can call in and access the mail. I know that represents a horrid waste of resources, but it's SAFE, I can control the access totally, and don't have the security concerns that exist on the Xenix side, due to my lack of experience. I'd be delighted to see a bbs package that would let me offer the mail to my users right HERE, at the source, without shelling anywhere. Ideally, this bbs software would understand the news, protect moderated groups, etc. without using vnews, rn, whatever. Perhaps in a year or two I might be comfortable with shelling to specified executables, but no way I'll permit it now....maybe one of you guys with the talent will provide our "dream system" one day, even though, from your point of view, it's already here :-) cheers/ -- 1B Systems Management Ltd. | 4B - 2520 Bowen Road, Nanaimo, B.C. V9T 3L3 Kenneth McVay | Voice: 604-758-7414 | Envoy: ken.mcvay | RCSA: 89:681/1 ------> uunet!van-bc!oneb!kmcvay |
karl@ddsw1.MCS.COM (Karl Denninger) (02/16/90)
In article <1990Feb15.072929.22712@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Feb13.214855.4265@ddsw1.MCS.COM> karl@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@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"
dell@Apple.COM (Thomas E. Dell) (02/16/90)
peter@ficc.uu.net (Peter da Silva) writes: >I don't understand this aversion to giving BBS users UNIX ids. You can >make the BBS program their login shell and have all the advantages of >a secure environment, and you won't have to do any special gyrations >to get mail working. > >Sure, there are a handful of interactive programs you have to hack, but >there are more free mailers/editors/pagers that you can hack the way you >like than you can shake a stick at. > >Really, what's the problem? With say 2,000 BBS users, I would prefer they all use one group account than add two thousand unnecessary lines to the password file. And if you play games with getty, you can make it so that dialup BBS users receive your BBS directly, instead of /bin/login. No one will try to break into 'root', 'uucp', etc. as it tempting with Unix BBS's. The approach taken by Waffle is to include mail & news as an integral part of the BBS - there is no worry of escaping out of external programs, and you have considerably more control over which newsgroups users may have access to {post,read}. This also leads to a much nicer UI. Of course if you WANT to do this via externals ("roll your own"), you can, but it isn't recommended. For importing mail, a program is supplied to receive mail diverted from smail or sendmail aliases. This may require a large number of aliases, but I prefer this method over granting individual accounts or using an "akcs." prefix in front of everyone's username. Like AKCS, waffle is also commercial ($100 for Xenix source, contact root@vox.darkside.com for details if anyone is interested). ...Tom dell@apple.com / root@vox.darkside.com / Thomas E Dell
larry@nstar.UUCP (Larry Snyder) (02/16/90)
In article <1899@oneb.UUCP>, kmcvay@oneb.UUCP (Ken McVay) writes: > > I know AKCS will handle this, but I keep hoping something less expensive > will come along (I've been spoiled by Opus/Fido/FrontDoor/SEAdog quality - > the dos world abounds with superb packages at reasonable prices) so that Ken - AKCS prices (last time I checked) started as low as $89 (for 286 based machines) with 386 versions available for $149. I consider those prices in the same range as SEADOG/FrontDoor - since Seadog was selling for $90 - and that was only the front end (no BBS package). -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry 4 inbound dialup high speed line public access system
palowoda@fiver.UUCP (Bob Palowoda) (02/17/90)
From article <LER1FK4xds13@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): > I don't understand this aversion to giving BBS users UNIX ids. You can > make the BBS program their login shell and have all the advantages of > a secure environment, and you won't have to do any special gyrations > to get mail working. > > Sure, there are a handful of interactive programs you have to hack, but > there are more free mailers/editors/pagers that you can hack the way you > like than you can shake a stick at. > > Really, what's the problem? Hmm, I guess I can make a comment here after running a bbs for a while. First when attracting first time users to a bbs specially a UNIX bbs you want to make the editors very easy to use. And you want the editors to resemble what the more popular bbs in dos type world uses. Something like the PC-Board editors. Lots of online menu most likely able to use ansi sequences and ibm graphics characters to format the menus. So far this dosn't exsist. Or I just haven't seen it yet. Also vi is out. Try teaching over 2000 people vi online. There are editor that control security level like 'Fenix'. However last time I checked there was no online default help menu that pops up when entering the editor. As for not createing an account for every user I tend to agree with the other sysops. Not so much as a security reason. But for the fact of system accounting. I would rather have the bbs program maintain itself and not use UNIX to do it. A database of user account info, paths termtypes which also the user could setup through 'none unix account methods'. Try teaching a first time user unix accounting and you will see what I mean. Maybe Karls bbs has this already. I haven't seen it. As for the mail program ELM would be perfect with the shell functions stripped out. I figure I could use some sort of system alais to the bbsuser.first.lastname and let sendmail handle it. Once again this should fit in with the proper editor like I mention above and be coupled into a security level of the user database info. Also the database could control the local users mail in another directory by the user without going to the system. Out of all the UNIX type bbs I have tried none of them meet all the above needs. I use XBBS because of it's user interface. Dosn't mean it's the best. It's a bear to maintain. But I give high marks for the user interface. Does it make a difference. I should think so, it may where your future customers get thier first impression. Or last. ---Bob -- Bob Palowoda pacbell!indetech!palowoda *Home of Fiver BBS* login: bbs Home {sun|daisy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB Voice: (415)-623-7495 Public access UNIX XBBS
allbery@NCoast.ORG (Brandon S. Allbery) (02/18/90)
As quoted from <999@fiver.UUCP> by palowoda@fiver.UUCP (Bob Palowoda): +--------------- | First when attracting first time users to a bbs specially a UNIX bbs you | want to make the editors very easy to use. And you want the editors to | resemble what the more popular bbs in dos type world uses. Something +--------------- Peter specifically mentioned *freeware* editors, *not* vi. As far as editors with automatic pop-up help menus, take a look at MicroEmacs sometime. (Not that I recommend dumping a novice into Emacs....) +--------------- | As for not createing an account for every user I tend to agree with | the other sysops. Not so much as a security reason. But for the fact | of system accounting. I would rather have the bbs program maintain itself | and not use UNIX to do it. A database of user account info, paths termtypes +--------------- Nobody said you had to turn on system accounting to use Unix user IDs; use the same accounting methods you would with any other Unix BBS. Way back when, I considered using Unix user names and giving each user his/her own account; I rejected it because "login:" (and "Login incorrect") are rather unfriendly... not to mention BSD-based systems and AT&T's 3B/2's which don't accept what your typical user expects for a backspace (BSD systems I've used demand DEL; 3B/2's want #. (Yes, pound sign! Welcome to the 90's, now go buy an ASR33! ;-) ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!cwjcc.cwru.edu!ncoast!allbery ncoast!allbery@cwjcc.cwru.edu
randy@chinet.chi.il.us (Randy Suess) (02/19/90)
In article <1990Feb15.204106.8719@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:
]
]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.
]
This was during the time of extreme security paranoia. Chroot
(under sysVr3.1 on a 3b2) worked out quite well, including
a complete seperate set of /dev entries, links to most /usr stuff
(/bin and /etc stuff had to be duplicated). A number of programs
were modified to work across the chroot partitions, including
the conferencing system, and the party program. Email was
strictly within the chrooted area.
It was finally removed due to other policy decisions, not because
of unworkability.
-randy
--
Randy Suess
randy@chinet.chi.il.uskarl@ddsw1.MCS.COM (Karl Denninger) (02/19/90)
In article <1990Feb18.180120.22530@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: >In article <1990Feb15.204106.8719@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >] >]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. >] > This was during the time of extreme security paranoia. Chroot > (under sysVr3.1 on a 3b2) worked out quite well, including > a complete seperate set of /dev entries, links to most /usr stuff > (/bin and /etc stuff had to be duplicated). A number of programs > were modified to work across the chroot partitions, including > the conferencing system, and the party program. That's interesting; I would think that if the conferencing package was looking for a base directory (from a common reference) nothing would have to be done other than having two "directing" files.... but then again, I know little of the internals of Picospan (what is running over on Chinet) In fact, AKCS was designed with just this in mind; when we were doing the chroot thing ourselves it was during the time that AKCS was being originally designed and that was a major part of it. > Email was > strictly within the chrooted area. Which is a problem if you want people to be able to get/send offsite mail :-) > It was finally removed due to other policy decisions, not because > of unworkability. Yep. We stopped using it here partly because of problems with disk space (we don't have unlimited room available on that machine) and partly due to the decision which was made not to grant shell access to other than system contributors. It certainly did work, although we never put the time into making email operate properly across the chroot()ed area. The entire "security" thing may come back with a vengence. There have been a couple of incidents lately which may end up having a large impact on the future of "freely available" shell access..... one would hope not, but it seems as though allowing that kind of free roaming is asking for far more trouble than it is worth..... -- Karl Denninger (karl@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"
randy@chinet.chi.il.us (Randy Suess) (02/19/90)
In article <1990Feb18.212134.15800@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:
]>]
]> A number of programs
]> were modified to work across the chroot partitions, including
]> the conferencing system, and the party program.
]
]That's interesting; I would think that if the conferencing package was
]looking for a base directory (from a common reference) nothing would have to
]be done other than having two "directing" files.... but then again, I know
]little of the internals of Picospan (what is running over on Chinet)
]
Picospan has hard coded path names in it, so I had to have
two versions, one in the chroot partition pointing to
the normal conference tree, /usr/bbs and the modified pico
pointing to the chrooted partition, /usr/guest/usr/bbs,
usr/guest being the chroot partition.
]In fact, AKCS was designed with just this in mind; when we were doing the
]chroot thing ourselves it was during the time that AKCS was being originally
]designed and that was a major part of it.
]
Picospan was designed back when UNIX ran on tube based computers.
]> Email was strictly within the chrooted area.
]
]Which is a problem if you want people to be able to get/send offsite mail :-)
]
Which was the primary reason for running the chroot stuff.
Temporary guests can't email AT&T source code to themselves.
This is what started the whole security paranoia thing.
Seems chinet is used alot by local Bell Lab's people.
I have more fake logins belonging to AT&T Security people
than regular users!
]> It was finally removed due to other policy decisions, not because
]> of unworkability.
]
]Yep. We stopped using it here partly because of problems with disk space
](we don't have unlimited room available on that machine) and partly due to
]the decision which was made not to grant shell access to other than system
]contributors.
]
I decided that I am running an public access UNIX system, and
if guests cannot access all that UNIX can give them, I might
as well shut it all down. Paranoia was no fun.
]The entire "security" thing may come back with a vengence. There have been a
]couple of incidents lately which may end up having a large impact on the
]future of "freely available" shell access..... one would hope not, but it
]seems as though allowing that kind of free roaming is asking for far more
]trouble than it is worth.....
]
It is interesting that I havn't seen anything on the net
about the above. A local UNIX bbs was shutdown/confiscated
by a 3 letter agency because of having the unfortunate
distinction of being home to the 911 crackers a few weeks
back.
]Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
--
Randy Suess
randy@chinet.chi.il.usmorrison@ficc.uu.net (Brad Morrison) (02/20/90)
In article <1990Feb13.214855.4265@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >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. What about having a wrapper around the real shells that only execs the real one if the user id is below some threshold? Then give your restricted users IDs above the threshold. --
kmcvay@oneb.UUCP (Ken McVay) (02/20/90)
In article <LER1FK4xds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > Sure, there are a handful of interactive programs you have to hack, but > > Really, what's the problem? The "problem" is that many of us (new to unix) folks neither know what, where, or HOW to "hack," nor do we WANT to. And, if I may be so bold to make a prediction, as more and more "illiterati" join the ranks of 386-owning, *IX- running system administrators, the demand for hackless uucp-capable, news- reading bulletin board systems will increase sharply....as will the desire to provide them. I'm delighted that you enjoy programming - we couldn't get along without you - but I don't, and products that require me to do so won't fly. This is not to say that those who have worked so hard to provide the systems that DO exist aren't appreciated - they are - but their systems never achieve full potential on "no-hacker" systems, and never will. As hardware costs come down, and o/s costs follow, the need for friendlier bbs software will increase...hopefully it will one day reach the friendly functionality of Opus, Fido, QBBS, RemoteAccess, PCBoard and RBBS-PC :-) -- 1B Systems Management Ltd. | 4B - 2520 Bowen Road, Nanaimo, B.C. V9T 3L3 Kenneth McVay | Voice: 604-758-7414 | Envoy: ken.mcvay | RCSA: 89:681/1 ------> uunet!van-bc!oneb!kmcvay |
karl@ddsw1.MCS.COM (Karl Denninger) (02/20/90)
In article <1990Feb19.135042.3950@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: >In article <1990Feb18.212134.15800@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: ................. >]> Email was strictly within the chrooted area. >] >]Which is a problem if you want people to be able to get/send offsite mail :-) >] > Which was the primary reason for running the chroot stuff. > Temporary guests can't email AT&T source code to themselves. > This is what started the whole security paranoia thing. > Seems chinet is used alot by local Bell Lab's people. > I have more fake logins belonging to AT&T Security people > than regular users! Which says something for (or against, depending on your point of view) for validation of all new users before you grant then access, or at least before you grant them continued access. I have caught a couple of "security spooks" on our system once or twice. They were summarially ejected since they didn't provide accurate and honest registration information. One was caught on-line and disconnected while logged into ANOTHER user's account! The person who's account was penetrated (using what may or may not have been illegal means) declined to take further action after being notified (other than changing the account password). >]> It was finally removed due to other policy decisions, not because >]> of unworkability. >] >]Yep. We stopped using it here partly because of problems with disk space >](we don't have unlimited room available on that machine) and partly due to >]the decision which was made not to grant shell access to other than system >]contributors. >] > I decided that I am running an public access UNIX system, and > if guests cannot access all that UNIX can give them, I might > as well shut it all down. Paranoia was no fun. I agree that paranoia is no fun. For a personally-owned system I can be seen to agree that it's no "big deal" if the system someday goes away on you for an indefinite period of time, or even permanently. On the other hand I wouldn't like it at all, and aren't about to allow it if I can help it. For a commercially owned machine it's an entirely different game, especially if you have a nice Ethernet between systems (then all of them are subject to "going away"). Scratch one business. >]The entire "security" thing may come back with a vengence. There have been a >]couple of incidents lately which may end up having a large impact on the >]future of "freely available" shell access..... one would hope not, but it >]seems as though allowing that kind of free roaming is asking for far more >]trouble than it is worth..... >] > It is interesting that I havn't seen anything on the net > about the above. A local UNIX bbs was shutdown/confiscated > by a 3 letter agency because of having the unfortunate > distinction of being home to the 911 crackers a few weeks > back. Oh, but we have. Do you read comp.dcom.telecom? The little fiasco with the E911 people was described there, and it made my blood run cold. What if that file on the E911 system had been, Gods forbid, posted to the net? The owner's involvement or cooperation in this particular case isn't at issue; he wasn't named in the indictment, and to my knowledge isn't under suspicion of any wrongdoing. Nonetheless, his machine is at the present time not in his possession, and while we all hope it is returned soon, it could remain "gone" until the trials of the people who have been indicted. That could easily be >years< from now! Folks, having the FBI come to my door and asking for dump tapes from my system to prove that someone did a bad thing is one thing, but having them come and take the >machine<, when I was not personally involved in the wrongdoing, is NOT OK. How, without the security being damn tight, do you prevent it from happening to you or I? If you give out shell access to anyone who asks, you may find one day that you too have some "classified" (or proprietary) information on the system -- when the 3-letter agencies come knocking on your door. Security scans are one thing, but they won't find things that don't have obvious names (or contents). How many of us "grep" every text file on the system, and even if you do what if the user in question does a simple rotation on the file to thwart this investigation? The problem is by no means small. The only real solution seems to SEEK AND GET common carrier status -- which solves the problem. It's the reason the phone company doesn't get seized when a drug deal is done over the phone. With common carrier status the BBS/Public Access system owner is exempt from having his/her equipment grabbed unless the authorities can show that he/she knew that the activity was going on and permitted it (or worse, took part!) In other words, unless you are charged with a crime (or indicted), your equipment is safe. They can still ask for your records (if you keep them) and/or dump tapes, but your equipment stays where it belongs. This is what every public-access site, every BBS, needs. Common carrier status. There are precedents for this -- CI$ has it, for example. Why not the "little guys"? As things sit now all public-access sites which grant access to the shell, for pay or not, are in jeopardy due to a few twits. I know this isn't exactly the right place for this kind of posting, but it IS something to think about if you currently offer (or are thinking of offering) public access to your Unix system. Your machine could be next. There is currently work being done on this very item. Stay tuned. Send support (just voices at this point please) here; I'll forward the notes to the appropriate parties. -- Karl Denninger (karl@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"
cpcahil@virtech.uucp (Conor P. Cahill) (02/21/90)
In article <.OV1S=Axds13@ficc.uu.net> morrison@ficc.uu.net (Brad Morrison) writes: >What about having a wrapper around the real shells that only execs the >real one if the user id is below some threshold? Then give your restricted >users IDs above the threshold. Because all that would need to happen is that the user's find out what the name of the real shell. Of course, a better solution would be to place the shell into a different group and set the modes to 0750. Then you could set up the group of the incomming users so that only those within said group can run the applicable program. However, this could cause lots of problems when the user tries to execute a function/program that depends upon the shell being available for non-interactive work (such as getcwd() on a system V system), then these functions would fail unexplicably. The best answer is still a chrooted environment or a much better controlled environment. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
karl@ddsw1.MCS.COM (Karl Denninger) (02/21/90)
In article <.OV1S=Axds13@ficc.uu.net> morrison@ficc.uu.net (Brad Morrison) writes: >In article <1990Feb13.214855.4265@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: > >>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. > >What about having a wrapper around the real shells that only execs the >real one if the user id is below some threshold? Then give your restricted >users IDs above the threshold. But what if the user finds out the real shell's name? SUID'ing the "wrapper" program won't work either, since it has to set the user id's to the real ones >before< it execs the real shell, and thus you again can get caught out. 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. Once a user finds out what you called /bin/sh (if you rename it) they can have a jolly good time using the same method as above. -- Karl Denninger (karl@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"
frk@mtxinu.COM (Frank Korzeniewski) (02/22/90)
In article <1990Feb20.191019.9391@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: #In article <.OV1S=Axds13@ficc.uu.net> morrison@ficc.uu.net (Brad Morrison) writes: #>What about having a wrapper around the real shells that only execs the #>real one if the user id is below some threshold? Then give your restricted #>users IDs above the threshold. # #Because all that would need to happen is that the user's find out what the name #of the real shell. Of course, a better solution would be to place the shell #into a different group and set the modes to 0750. Then you could set up the #group of the incomming users so that only those within said group can run #the applicable program. However, this could cause lots of problems #when the user tries to execute a function/program that depends upon the #shell being available for non-interactive work (such as getcwd() on a system #V system), then these functions would fail unexplicably. # #The best answer is still a chrooted environment or a much better controlled #environment. Brads idea could be extended just a little bit to overcome your objections. Just use bash or ash for which the source is available and put the wrapper check on the user id into the shell source code. Lets see a user get around this!! Frank Korzeniewski (frk@mtxinu.com)
morrison@ficc.uu.net (Brad Morrison) (02/22/90)
>>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."
karl@ficc.uu.net (Karl Lehenbauer) (02/23/90)
In article <PYX1O.9xds13@ficc.uu.net> morrison@ficc.uu.net (Brad Morrison) writes: >But you don't want to exclude 'vi', I don't think. What about replacing >it, instead of replacing the shell? Yeah, and elvis is a good vi clone, even superior to vi in some respects. It's still a pain to go in an edit it to not have shell escapes and to not allow entering arbitrary pathnames/filenames, but it's in our BBS-to-do job jar. -- -- uunet!ficc!karl "...as long as there is a Legion of super-Heroes, uunet!sugar!karl all else can surely be made right." -- Sensor Girl
cpcahil@virtech.uucp (Conor P. Cahill) (02/24/90)
In article <1134@mtxinu.UUCP> frk@mtxinu.UUCP (Frank Korzeniewski) writes: >Brads idea could be extended just a little bit to overcome your objections. >Just use bash or ash for which the source is available and put the wrapper >check on the user id into the shell source code. Lets see a user get >around this!! Fine. This could be done. However, you will still break any program that does a popen(). (or calls a library routine that does a popen()). In addition most system administrators will not want to rely on anything other than the stock sh or csh for system administration work. If you replaced /bin/sh with bash, you would be opening lots of doors for lots of problems with the system administration shell scripts. If you are going to leave the real shell around somewhere else, then you have the problem of the user's finding out where it is. These kind of security problems have lots of quick answers, but with a little thought a persistant person can get around most of them. I still think the "best" answer is to have the restricted persons run in a chroot()ed environment because there is no way to get out of there. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
peter@ficc.uu.net (Peter da Silva) (02/27/90)
> The "problem" is that many of us (new to unix) folks neither know what, where, > or HOW to "hack," nor do we WANT to. And, if I may be so bold to make a > prediction, as more and more "illiterati" join the ranks of 386-owning, *IX- > running system administrators, the demand for hackless uucp-capable, news- > reading bulletin board systems will increase sharply....as will the desire > to provide them. So what you're saying is that there's a market for small, friendly, bbs- compatible programs like editors, mail readers, and so on. One of these days I'll get the Sugarland UNIX software into shape. But that really doesn't explain why none of the existing UNIX-based BBS programs make more than a token attempt to be well-integrated with UNIX. Which is, after all, the point. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
david@oldcolo.UUCP (David Hughes Jr) (03/04/90)
Have followed this string with interest. I am attempting to bring up UFGate under Opus. Has anyone out there done this? I have Opus and UFGate installed, all the control files making proper calls (according to docs). But it doesn't work. Anyone doing UFGate and can answer some questions (outside this conference)? david hughes
larry@nstar.UUCP (Larry Snyder) (03/05/90)
In article <W+-1B-Fxds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > So what you're saying is that there's a market for small, friendly, bbs- > compatible programs like editors, mail readers, and so on. One of these > days I'll get the Sugarland UNIX software into shape. I'm looking for a good small safe wordstar compatible editor for use under 386/ix (or Xenix). -- The Northern Star Public Access Unix Site, Notre Dame, Indiana USA uucp: iuvax!ndmath!nstar!larry internet: larry@nstar USR HST 219-287-9020 * PEP 219-289-3745 * Hayes V9600 219-289-0286
roy@comcon.UUCP (Roy M. Silvernail) (03/05/90)
In article <511237@nstar.UUCP>, larry@nstar.UUCP (Larry Snyder) writes: > > I'm looking for a good small safe wordstar compatible editor for use > under 386/ix (or Xenix). I was looking for just about the same thing, and found nada... so I grabbed the stevie source, installed a new restricted_user command, and put it up on my BBS for the users. No, it's not as easy to use as WS-types, but it's lots more powerful, and the users in the programming cadre really like it! -- _R_o_y _M_. _S_i_l_v_e_r_n_a_i_l | UUCP: uunet!comcon!roy | "Every race must arrive at this #include <opinions.h>;#define opinions MINE | point in its history" SnailMail: P.O. Box 210856, Anchorage, | ........Mr. Slippery Alaska, 99521-0856, U.S.A., Earth, etc. | <Ono-Sendai: the right choice!>
uimop@alake.FIDONET.ORG (Greg Sheppard) (03/08/90)
DH> Anyone doing UFGate and can answer some questions (outside this confer David, I'm running UFGate with Searchlight BBS software. Not quite the same as Opus, but it's working pretty good. Give me a call and we can continue this voice. -- Greg Sheppard Telephone: 1-206-581-4276 imop@alake.UUCP Work: 1-206-581-8924
david@oldcolo.UUCP (David Hughes Jr) (03/14/90)
I just installed UFGate too. Works smooth. It was all the other MSDOS BBS software that drove me to insanity. Now running though. Can you give a quickie paragraph on Searchlight software? tx, david hughes uucp: oldcolo!david