Bell Labs or Microsoft security?

Leo Bicknell bicknell at ufp.org
Wed Jan 29 14:41:02 UTC 2003


In a message written on Wed, Jan 29, 2003 at 03:32:41AM -0500, Sean Donelan wrote:
> Multics security. Bell Labs answer: Unix. Who needs all that "extra"
> security junk in Multics.  We don't need to protect /etc/passwd because
> we use DES crypt and users always choose strong passwords.  We'll make
> the passwd file world readable so we can translate uid's to usernames.
> Multi-level security? Naw, its simplier just to make everything Superuser.

A choice made what, 20 years ago?  Almost every major form of unix
moved to shadow password files and/or stronger password protection
years ago.

> FORTRAN/COBOL array bounds checking.  Bell Labs answer: C. Who wants
> the computer to check array lengths or pointers.  Programmers know what
> they are doing, and don't need to be "constrained" by the programming
> language. Everyone knows programmers are better at arithmatic than
> computers.  A programmer would never make an off-by-one error. The
> standard C run-time library.  gets(char *buffer), strcpy(char *dest, char
> *src), what were they thinking?

Again, a choice made perhaps 20 years ago?  New libraries and
languages make solving this problem much easier.  New tools are
available to catch it when it does happen, even in traditional C.

We can't expect people to never make mistakes.  Rather, the bar
must be set that once a mistake is made and understood we strive
never to make it again.  The choices you site were made at a very
different time, and for very different reasons.  I highly doubt
if Bell Labs had to make choices today that they would choose the
same outcome.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20030129/368486e1/attachment.sig>


More information about the NANOG mailing list