Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!mwp@munnari
From: mwp@munnari (Michael Paddon)
Newsgroups: comp.unix.wizards
Subject: Re: Unexpected NFS Effects
Message-ID: <1602@munnari.oz.au>
Date: 21 Jun 89 02:19:46 GMT
References: <1703@softway.oz>
Sender: news@cs.mu.oz.au
Reply-To: mwp@munnari
Lines: 30

From article <1703@softway.oz>, by chris@softway.oz (Chris Maltby):
> 
> So that's how it is, I'm sure. The question now is "Why?". I can't think
> of any reason why you couldn't pass a "read for execution" request distinct
> from a "read as data" request. I guess someone crocked the design... (:-)

How would this increase security? All I can see is more complexity in
the protocol for absolutely no return.

All root has to do is construct a request that says "read this
file for execution". Sure, it's a little harder, but we all know how
useful security via obscurity is (even if you don't have NFS source).

The other point to remember is that NFS is a general protocol (not Unix
specific). It just requires that there is a trusted context which does
stuff like executing files. In Unix, that context is the kernel; for
historical reasons the kernel and root are trusted equally from the
security viewpoint.

The way to provide security is to ensure that the root account *and* the
kernel can be trusted. A third party authentication scheme fits the bill
nicely.

-------------------------------------------------------------
|                  | email: mwp@munnari.oz.au               |
|                  | voice: (03) 344 4246                   |
|  Michael Paddon  | snail: Department of Computer Science, |
|                  |        The University of Melbourne,    |
|                  |        Parkville 3052, Australia       |
-------------------------------------------------------------