Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!blake!Tomobiki-Cho!mrc
From: mrc@Tomobiki-Cho.acs.washington.edu (Mark Crispin)
Newsgroups: comp.sys.next
Subject: Re: NeXT concerns
Message-ID: <677@blake.acs.washington.edu>
Date: 29 Jan 89 21:05:11 GMT
References: <4474@umd5.umd.edu> <32681@tut.cis.ohio-state.edu> <33@xenlink.UUCP> <669@blake.acs.washington.edu> <32926@tut.cis.ohio-state.edu>
Sender: news@blake.acs.washington.edu
Reply-To: mrc@Tomobiki-Cho.UUCP (Mark Crispin)
Organization: Mendou Zaibatsu, Tomobiki-Cho, Butsumetsu-Shi
Lines: 45


OK, since you didn't understand last time, let me put it another way:

If you set up external access via the r* tools, or use NFS, you don't
have any security on your system worth a damn.  This has been
repeatedly and convincingly demonstrated.

If you allow security data (including passwords) to be transmitted in
plaintext then you don't have any security on your system worth a damn.

If you allow security data (including passwords) to be available in
any form (even if encrypted) to processes which do not have an
absolute need for this data then you don't have any security on your
system worth a damn.

File write protections on most operating systems (including Unix) are
useful mostly to prevent accidental overwriting or destruction of
system files and do not protect against intentional overwriting or
destruction.

File read protections on most operating systems (including Unix) are
useful mostly to prevent accidental reading of private files and do
not protect against intentional reading.

The vast majority of Unix tools were put together without system
security implications in mind.  In general, the tools were developed
by expert users intending these tools to be used by other expert users
with non-hostile intent, e.g. the use of gets() in many tools.

Unix is not a secure operating system, particularly with the r* and
NFS networking facilities enabled.  In many ways, it is less secure
than the completely unprotected ITS operating system, because the
half-hearted attempts at security it does make offers incentive to
crackers to show off.  Furthermore, it introduces a false sense of
security.  It is indeed cretinous to assume that your Unix system is
secure.

Keeping these things in mind, it is possible to configure your Unix so
that your typical cracker will go away quite frustrated and bother
someone else.  Such configurations may involve some inconvenience; as
Brian Reid noted, "system programmer convenience is often the
antithesis of security."

I feel that buggering a workstation to deny its user control over it
is a step in the wrong direction.