Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!apollo!mishkin
From: mishkin@apollo.COM (Nathaniel Mishkin)
Newsgroups: comp.unix.wizards
Subject: Re: RPC == setuid procedure call?
Message-ID: <3e11c29c.13422@apollo.COM>
Date: 25 Aug 88 12:54:00 GMT
References: <6890@umn-cs.cs.umn.edu>
Reply-To: mishkin@apollo.com (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 49

In article <6890@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes:
>I'm starting to learn about RPC for a project we're working on here, and I've
>come up with a question:
>
>	Is local RPC (i.e. Remote Procedure Call to a server on the local
>	host) usable as a setuid procedure call?
>
>It seems to me that if the RPC server is running as uid root, and you make an
>RPC to it, it should be able to do things for you, as root.  Is there a
>problem with this?  (Other than the obvious one of validating the caller
>for what he wants done!)
>
>Is this difficulty severe enough that only root should be allowed to make
>RPCs to a RPC server running as root?

I can't quite tell whether you're worried about a security problem or
trying to decide whether this property is a good idea.

Clearly it's up to all servers to decide whether they should perform
any given request made by a client.  Many RPC applications written to
date have just punted on the issue because either (a) it was too hard
to do authentication (and people were willing to assume a generally
trustworthy environment), or (b) what the servers did just wasn't that
sensitive (e.g. if the remote procedure is one that returns the number
of logged in users the server really doesn't care who's making the
request).  As more applications are written both of these cases will
tend to be less common.

One way of thinking about all this is that system calls (e.g. open, read,
write, fork, etc.) are just special cases of remote calls where the kernel
is the server, the user space application is the client, and the source
and target machines of the call are identical.  Given the nature of the
user-space / kernel relationship, the kernel can "know" the identity
of the caller and decide whether the operation should be performed.  This
isn't just random musings.  At Apollo we'd like to implement certain
kernel functionality as specially privileged (user-space) RPC server
processes that would get (at least most of) their calls from local clients.
(In fact, I think this is the basic model of Topaz, the DEC SRC operating
system.)  Thus, some things that are currently "system calls" (real traps
to the kernel) would become "remote" calls to local processes.  (Obviously
this scheme requires that intra-machine RPC be implemented efficiently
since you won't have "the slow network" to blame any more when the calls
don't go fast.)



-- 
                    -- Nat Mishkin
                       Apollo Computer Inc., Chelmsford, MA
                       mishkin@apollo.com