Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: Unexpected NFS Effects
Message-ID: <12274@bloom-beacon.MIT.EDU>
Date: 28 Jun 89 03:08:28 GMT
References: <403@fang.dsto.oz> <12025@bloom-beacon.MIT.EDU> <1703@softway.oz>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 29

In article <1703@softway.oz> chris@softway.oz (Chris Maltby) writes:
>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... (:-)

RFE = Read For Execution
RAD = Read As Data

First of all, a malicious user can lie and send an RFE and get the
binary image with little effort (it *really* isn't that hard to spoof
NFS packets :-).  Second, the distinction between RFE and RAD in an
ideal situation would be that only a kernel process would be allowed
to make an RFE, and that distinction cannot be enforced on the server
side, only on the client side.  Therefore, an RFE request would still
require that root on the client be trusted.  That's what's being
assumed under the present system, since any executable is readable by
root, so you don't gain anything by separating the operations.

Second, once you've actually got the binary image running on your
machine, I can think of any number of ways to get the actual contents
of the program image.  The first one that comes to mind is sending it
a signal that causes it to dump core and then undumping the core file
to get a binary.  How many programs do you know that trap *all*
signals and can prevent core dumps in all cases?

Jonathan Kamens			              USnail:
MIT Project Athena				432 S. Rose Blvd.
jik@Athena.MIT.EDU				Akron, OH  44320
Office: 617-253-4261			      Home: 216-869-6432