[ On Tuesday, April 24, 2001 at 15:00:31 (-0400), Anne Bennett wrote: ]
> Subject: Re: bin/12740: fstat allows an unprivileged user to see open files belonging to other users
>
> Well, the idea was to make it more restricted by default, leaving the
> sysadmin the option to unrestrict it if desired.  I am very happy to
> see that NetBSD is now shipping "closed by default" in the areas of
> network services, and I assumed that we would want to move in the same
> direction in other areas as well.

hiding system information unnecessarily should never be the default on a
unix-based system....  such a change would be a rather drastic shift in
direction for unix and would clash with most existing user's expectations

> I'm afraid I managed to miss the "silly discussion" about restricting
> ps; I imagine I would find it interesting and not silly, though.

It took (is taking) place on the <tech-kern@netbsd.org> mailing list.

I called it "silly" because I find it rather amusing that anyone could
*not* have expectations

> Striking a balance between security and convenience is always
> difficult and often controversial.  :-(

Indeed, which is where threat identification and risk analysis come into
the picture.

If you can't identify a real threat then the risk of any given feature
or activity has got to be pretty darn small, no?  :-)

If you have in fact identified a real threat then you can perform a
rational risk assessment and decide how best to deter or prevent the
threat from being carried out.  I would be most interested in learning
what real threats anyone can identify in allowing users to see some
currently "public" details about other user's system activities
(including of course general "system" activities as well).  I would be
even more interested in learning the results of any risk analysis
performed on such threats!

> Much as I find myself curious to know how you see restricting the
> "list open files" functions as inimical to community-building, I can
> see that I have stumbled into a religious war here, and that
> discussion might be a waste of time.

Unix systems, when used as secure computing platforms, have
traditionally been implemented as single-user systems.  I.e. it's often
been considered to be a bad thing to try to mix secure applications with
general purpose applications on a multi-user computing platform,
particularly when using a system that's not designed to keep such things
completely separate despite the fact that they all run on the same system.

The beauty of this is that computers are no longer so expensive as to
require merging of applications or groups of users with different levels
of security requirements on the same system.  Indeed networking
technology and secure client-server computing are even allowing users
and applications with different levels of security requirements to
interact productively even though they are not sharing the same system!

There are of course many many ways to *not* crack an egg!  ;-)

As to your implied question, well I think you'll find that in any
community of users using a single unix-based general purpose system
there are lots of intstances where these users assist each other by
using tools such as "ps", "lsof", "fstat", etc., etc., etc.  In more
traditional time-share environments such assistance would have had to
have been supplied solely by a sufficiently sized team of system
administrators and operators.  These days almost anyone with the desire
to do so can run their own private system and the reasons for using
shared multi-user systems are no longer always cost based but rather
more to do with co-operation and sharing -- i.e. to form communities.

Since any risk analysis must take into account all of the "costs"
associated with preventing or even deterring a threat it is important to
note that if one changes the system in such a way that superuser
privileges are needed to perform even basic user-level diagnotics on
behalf of some other user then one increases the level of risk the
system will face due to operator error.  Indeed the added load on
administrator and operator staff may even make it necessary for more
people to know the superuser passowrd, which will also raise the level
risk faced by the system.

In other words it's not so much of a religious war, as a matter of
practicality.

> Thanks to the wonders of open source, I have already recompiled lsof
> with the (IMHO) appropriate security options, and have simply disabled
> fstat on my system for now.

Indeed.
 
> My mailer is in fact configured correctly, but it was not used to send
> the PR in question; rather I used the web form on the www.netbsd.org
> site.  I'm a bit puzzled that this wasn't clear from the message headers.

Ah!  I see.  Very interesting indeed.  Perhaps the instructions on the
web form, and in particular the field where the sender's email address
is to be entered, need to be made more clear, though they seem fairly
clear to me right now.  Perhaps there's a bug in the form handling code
and it's confusing the e-mail field with the name field or some such, or
maybe it's not correctly parsing the value of the e-mail field.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>