Protecting against downloads

[Karl Denninger]

In article <1990Sep18.120450.14590 at nstar.uucp> larry at nstar.uucp (Larry Snyder) writes:
>heiser at tdw201.ed.ray.com writes:
>
>>What's a "public access unix" without shell access?  I want to provide
>>access for all of the reasons you mentioned here.  If I wanted to 
>>continue to ONLY allow access via a menu-driven program, I'd have no
>>reason to switch from my current dos bbs.
>
>come now - with unix (running waffle) you can spawn anything - one user
>can be in wordperfect, while another in foxbase, etc.  Waffle makes it
>very easy to spawn applications by users - yet maintains system security.
					    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>shell access can be risky - we have no shell access here at nstar, and
>for security reasons we intend to keep it that way.  

I hope you don't allow "vi" access, or you have the bbs in a "chroot"ed area
with no backlinked files (ie: no linked files between the areas).

If not, give me the phone number, and I'll have a user shell (ie: bourne 
shell) in 30 seconds flat after I get "vi" up.  I'll send you email from the
shell account, or "write" you as sufficient evidence that I was successful.

Without source code to "vi" there is NO WAY to prevent this.  Believe me.  
I had this rather graphically illustrated to me once; it's a flaw in the
way vi works.  There is simply no prevention available if the shell is
findable on the system ANYWHERE.  This means you need to "chroot" your
"open" bbs, or be VERY selective about what you let your users "shell out"
to.

This is also a great way for people who normally have a "restricted" shell 
to break out of it.  Editors are wonderful, aren't they?

This is the reason that AKCS' installation manual specifically recommends
against allowing users to use the "vi" editor if they are captive users 
(there's a file which lists the editors that are available to "bbs" users).

The documentation also tells 'ya to make sure your other editors and
packages you install as "callable" don't have this hole -- which in most 
cases means you need the source to same, or a high degree of confidence in 
the commercial package you're about to let users at.

Callable system utilities are a recipe for disaster without EXTREME care in
implementation or a chrooted area for the bbs in general.  In general, if
you want to let people at other facilities, it's best to either write your
own facilities, wrappers for same with a chroot in the middle, or chroot the
entire BBS system.  

The wrapper approach has it's own problems, as it has to run SUID root in
order to do the chroot, and that's a security risk in and of itself.

The only other alternative is to assign individual UNIX LEVEL accounts for
all the users, and put their home directories where they can't do any harm
(ie: /tmp, or a filesystem you don't care about).  The first (ie: /tmp) 
works IF your BBS keeps all it's indices internally; if it stores them 
somewhere in the user's directory structure you'll get in real big trouble 
with this scheme (this won't work with AKCS, for example).

Anyone who wants to test this theory can send me their system's phone number.
If you're running external stuff you purchased, or utilities that came with
the machine, and haven't taken these precautions, there's a good chance I 
can get a user shell in minutes.

--
Karl Denninger	AC Nielsen
kdenning at ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.