randy@umn-cs.cs.umn.edu (Randy Orrison) (08/23/88)
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?
All help appreciated!
--------
off the subject: I asked earlier what Sun OS people were running, and got a
request for a summary after I had thrown away quite a few letters. The
majority of sites were running 3.x, only a couple were running 4.0. Most
were waiting for 4.0 to settle down before trying the switch.
--
Randy Orrison Control Data in the Hills of Arden, MN
{bungia, uunet!hi-csc, rutgers, sun}!umn-cs!randy randy@ux.acss.umn.edusxn%ingersoll@Sun.COM (Stephen X. Nahm) (08/24/88)
In article <6890@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes: >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!) ... and that's what the authentication information is for. It's up to the server to determine whether the client is authorized to request that one of the server's procedures be executed. AUTH_NONE and AUTH_UNIX both provide little assurance to the server that the client is authentic, because these authentication modes do not have verifiers. AUTH_DES, which was introduced in SunOS 4.0, does have a verifier, and gives the server much better assurance that the client is genuine. Also, the source of Sun's RPC library is available free of cost. As a network applications developer, you could "roll your own" authentication mechanism, and use this for your server. >Is this difficulty severe enough that only root should be allowed to make >RPCs to a RPC server running as root? It depends on your application and operating environment. There are many useful functions that can be safely provided by a root server, even in a nonsecure environment. It's up to you, as the network applications developer, to make this judgement. Steve Nahm sxn@sun.COM or sun!sxn
mishkin@apollo.COM (Nathaniel Mishkin) (08/25/88)
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