On Wed, 6 Nov 1996, Greg A. Woods wrote:

> > A setuid root binary, no. But I seem to be having a great deal of
> > difficulty making you preceive that the problem is not just root
> > access, it's shell access of any kind.
> 
> But you can't do that by default on *bsd anyway!!!!

Of course you can. I've done it.

> If you
> want a box that can give you a secure platform that won't permit shell
> access, then you're going to have to drop almost all the way back to
> SysVr3.2, *or* do a lot of hacking on a lot of system utilities.

On which system utilities. Given that the only things running are
/bin/login, possibly an initial shell, and the application program,
where do the other utilities come in (unless someone's snuck in
some changed environment varibles)?

> Even a
> generic SysVr4 has lost this capability in the face of a dedicated
> cracker.

I'm not sure I see what System V has to do with all of this. Last
I checked, NetBSD was a BSD-based operating system.

> What I can't understand is why you think it's of value to restrict shell
> access to a general purpose system.

Because it means I don't have go around securing all the possible
holes that open up when users can run arbitrary programs. If I can
prevent a user from running a C compiler and lpr, for example, I've
stoped the lpr hole without having recompile lpr.

This is really the basis of a lot Unix security, in the end. We
allow certain classes of users to execute a restricted set of
programs, to limit the damage they can do. Remote UUCP sites can
run only rmail and rnews. Remote network sites can run only sendmail
and finger and whatever else you make available on a TCP port, and
those only with a limited set of options. People browsing the web
can run only the CGI scripts we make available to them.

> Certainly very few, if any, of the *BSD system utilities that provide
> shell access via escapes or what have you are prepared by default to
> enforce a security policy of not allowing shell access -- quite the
> contrary.

I'm not sure what this has to do with the argument, either. I'm
saying that the whole point is that we don't run most, if not all,
of those programs.

> In fact the proposed changes to login will *not* make it any easier to
> get shell access in a *stock* environment...

Ok. Forget, for a moment, the words `shell access' and think,
instead, `ability to execute an arbitrary program or read from or
write to an arbitrary file. Do you not see that many programs, even
if they don't allow shell escapes of any kind, can be convinced to
do interesting and (to a hacker) useful things if we can manipulate
their environment variables. If you're in doubt, go back to the
BoS list and look at many of the HP attacks that were posted
recently. A lot of these are executed by convincing a program to
write a file it shouldn't be writing.

> I admit they may make it more difficult to
> prevent users from contorting the behaviour of mega-monolithic
> applications which may place undue trust in various environment
> variables, but as we've discussed this can be prevented by appropriate
> access controls and wrapper programs -- no magic necessary.

In other words, you're going to make me spend half my life writing
wrapper programs so that you can add a feature that I don't want.
This seems silly.  Why are you intersted in making security harder,
rather than easier. The default should be that you *don't* have to
write wrappers, and you can modify your system so that you do have
to write all these wrappers if that's what your really want to
spend your time doing.

> That's where you're supposed to earn your money and you should be able
> to do the detective work necessary to discover them all!  ;-)

The problem is, I'm earning that money only because someone set up
login in such a way that I'm forced to charge my client to do more
work than I'd have to do otherwise.

> > Otherwise it's just one more
> > stupid little security hole that someone is going to forget to plug
> > one day, and it's going to hurt them.
> 
> Sorry, I do not agree.

Well, I had no idea that any version of login did this. What's
going to happen to some admin a year or two down the road who missed
this discussion? He's going to get bitten. This is why it should
be explicitly enabled by the administrator.

Keep in mind, also, that you've not dealt with the problem of the
admin who wants something particular executed in /etc/profile,
before the user goes on to do whatever it is he wants to do. How
do you secure that?

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.