Xref: utzoo comp.unix.xenix:10202 comp.unix.i386:3063 Path: utzoo!utgpu!jarvis.csri.toronto.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: Security (or lack thereof) and it's implications Message-ID: <1990Feb20.050249.18960@ddsw1.MCS.COM> Date: 20 Feb 90 05:02:49 GMT References: <1990Feb18.212134.15800@ddsw1.MCS.COM> <1990Feb19.135042.3950@chinet.chi.il.us> Reply-To: karl@mcs.MCS.COM (Karl Denninger) Organization: Macro Computer Solutions, Inc. - Mundelein, IL Lines: 116 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, !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"