daveb@llama.rtech.UUCP (Dave Brower) (07/09/88)
On a single machine, we have a suid server process. A random client
program wishes to connect and have the server perform some services. The
server wants to know who the client is before doing anything. They might
be communicating with sockets, fifos, msgs, or shared memory.
How can the server find out who the client is, in a spoof-proof and
secure way? On BSD, one can have the server ask the client to create a
randomly-named file, and the server can see who the owner of the file
is. On SV, this fails because the client can chown it to be anyone
else. (The same is true of msgs and shm segments).
Oh wise and knowledgeable Wizards, what is a Way?
Thanks,
-dB
---
"Ready when you are Raoul!"
{amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!gpowell@wizdom.UUCP (Glenn Powell) (07/09/88)
In article <2310@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes: >On a single machine, we have a suid server process. A random client >program wishes to connect and have the server perform some services. The >server wants to know who the client is before doing anything. They might >be communicating with sockets, fifos, msgs, or shared memory. > >How can the server find out who the client is, in a spoof-proof and >secure way? On BSD, one can have the server ask the client to create a >randomly-named file, and the server can see who the owner of the file >is. On SV, this fails because the client can chown it to be anyone >else. (The same is true of msgs and shm segments). You are correct that any SysV user can chown() a file to anyone else. BUT, if you require that the file be su'id they can't get away with it. The chown() call will clear the suid bit when it changes the ownership and nobody but root can set it on another person's file. SO, have the client create a file with user execute+suid and no access for other users. Make sure that they not only own the file; but, have it set suid. It is important that there not be any access for other users(for obvious reasons:). This does work with named pipes(I just tried it) so it might work with msgQ's and shared memory. But, I haven't tried that. Anybody know for sure? ______ _________ / ____/ /__ __/ Glenn Powell / /___ / / gpowell@wizdom.UUCP /___ / / / uunet!wizdom!gpowell ____/ / __/ /__ Software Innovations Inc., Kansas City /______/ /________/ Disclaimer: These opinions are MINE!
jfh@rpp386.UUCP (John F. Haugh II) (07/10/88)
In article <2310@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes: >How can the server find out who the client is, in a spoof-proof and >secure way? On BSD, one can have the server ask the client to create a >randomly-named file, and the server can see who the owner of the file >is. On SV, this fails because the client can chown it to be anyone >else. (The same is true of msgs and shm segments). > >Oh wise and knowledgeable Wizards, what is a Way? have the client create a file with the suid and sgid bits set. you can't chown a file after setting those bits without having some of them cleared. the documentation for chown(2) specifies that the SUID and SGID bits are cleared if either owner or group are changed. this should be fully fool proof. - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
steiner@athena.mit.edu (Jennifer Steiner) (07/10/88)
In article <2310@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes: >On a single machine, we have a suid server process. A random client >program wishes to connect and have the server perform some services. The >server wants to know who the client is before doing anything. They might >be communicating with sockets, fifos, msgs, or shared memory. > >How can the server find out who the client is, in a spoof-proof and >secure way? Project Athena has an authentication service (called Kerberos) which we use to deal with this problem. Here's a simplified description of how it works: There's a trusted, secure authentication server which knows the keys (like passwords) of all its clients - both users and network servers have keys. When a program running on behalf of a user wants to authenticate the user's identity to some server, it goes to Kerberos (the authentication server) and requests a "ticket" for the server. Kerberos creates and returns the ticket to the user. The ticket is encrypted in the server's key and contains the identity of the user. When the user's program contacts the network server, typically the first thing it sends is this ticket. The server decrypts it to find out the identity of the user. Since only the server and Kerberos know the server's key, and the ticket is encrypted in the server's key, the server knows that the ticket was issued by Kerberos and believes what it says about who the user is. Issues that I won't go into in detail here, but that Kerberos does deal with, include: authenticating the user to Kerberos in the first place; authenticating the server back to the client; allowing the client to re-use a ticket for a given server without allowing impostors to use "re-use" it too; distributing a temporary encryption key to the client and server so that they may encrypt their communication; expiration of tickets; etc. If you're interested in the gory details, you can get documents via anonymous ftp from "athena-dist.mit.edu" (18.71.0.38). Jennifer Steiner P.S. Kerberos is in beta test now. We don't yet know when or how we'll make it generally available, but we'll post a message when we do.
avr@mtgzz.att.com (XMRP50000[jcm]-a.v.reed) (07/13/88)
In article <2310@rtech.rtech.com>, daveb@llama.rtech.UUCP (Dave Brower) writes:
< On a single machine, we have a suid server process. A random client
< program wishes to connect and have the server perform some services. The
< server wants to know who the client is before doing anything. They might
< be communicating with sockets, fifos, msgs, or shared memory.
<
< How can the server find out who the client is, in a spoof-proof and
< secure way? On BSD, one can have the server ask the client to create a
< randomly-named file, and the server can see who the owner of the file
< is. On SV, this fails because the client can chown it to be anyone
< else. (The same is true of msgs and shm segments).
<
< Oh wise and knowledgeable Wizards, what is a Way?
On Sys V: Have the client tell you its uid. To verify, open a file
with mode 002 in a directory which is writable only by you, but is
readable by and known to the client. Then write a newly-generated
random content into that file, change the mode of the file to 004,
and chown it to the uid the client gave you. Then have the client
read its content back to you, and compare it with what you wrote
to the file. If they match, the client is who he says he is.
Adam Reed
mtgzz!avrjc@minya.UUCP (John Chambers) (07/21/88)
In article <3789@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: > In article <2310@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes: > >How can the server find out who the client is, in a spoof-proof and > >secure way? On BSD, one can have the server ask the client to create a > >randomly-named file, and the server can see who the owner of the file > >is. On SV, this fails because the client can chown it to be anyone > >else. (The same is true of msgs and shm segments). > > > >Oh wise and knowledgeable Wizards, what is a Way? > have the client create a file with the suid and sgid bits set. you > can't chown a file after setting those bits without having some of > them cleared. the documentation for chown(2) specifies that the SUID > and SGID bits are cleared if either owner or group are changed. Let's see, what I do when you ask my process A to create this file is to have a program B sitting around that is setuid/setgid to whomever I want you to think A is; A would start up B as a subprocess, with the desired filename in argv[1]; B would create it. How would you determine that A isn't this uid/gid combination? > this should be fully fool proof. Careful who you call a fool, boy! [Goddam @#*$&^ included-line-count nonsense ;-] -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
karish@denali.stanford.edu (Chuck Karish) (07/21/88)
In article <51@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >In article <3789@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: >> In article <2310@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes: >> >How can the server find out who the client is, in a spoof-proof and >> >secure way? >> have the client create a file with the suid and sgid bits set. >Let's see, what I do when you ask my process A to create this file is >to have a program B sitting around that is setuid/setgid to whomever >I want you to think A is; A would start up B as a subprocess, with the >desired filename in argv[1]; B would create it. How would you determine >that A isn't this uid/gid combination? This describes a situation in which the user has successfully created a live Trojan horse. It means that the user has cooperation from the owner of the setuid file, or knew the super user password at some time in the past. In either case, security has been compromised in ways that can't be detected under SysV. An obvious administrative fix is to scan periodically for setuid programs. Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
matt@oddjob.UChicago.EDU (Ka Kahula) (07/22/88)
) In article <3789@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: ) > have the client create a file with the suid and sgid bits set. ... In article <51@minya.UUCP> jc@minya.UUCP (John Chambers) writes: ) Let's see, what I do when you ask my process A to create this file is ) to have a program B sitting around that is setuid/setgid to whomever ) I want you to think A is; ... If you have this program B, you can impersonate your victim completely. Why not just assume that you have your victim's password? It comes to the same thing. A would start up B as a subprocess, with the ) > this should be fully fool proof. ) ) Careful who you call a fool, boy! No error in this case. ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu
maart@cs.vu.nl (Maarten Litmaath) (07/22/88)
In article <51@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
\...
\[Goddam @#*$&^ included-line-count nonsense ;-]
Why don't you just change your follow-up character (>), just like I (\) did?
--
I'd rather live in Russia |Maarten Litmaath @ Free U Amsterdam:
than in South-Africa... |maart@cs.vu.nl, mcvax!botter!ark!maartdmcanzi@watdcsu.waterloo.edu (David Canzi) (07/22/88)
In article <14931@oddjob.UChicago.EDU> matt@oddjob.UChicago.EDU (Ka Kahula) writes: >) In article <3789@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: >) > have the client create a file with the suid and sgid bits set. ... > >In article <51@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >) Let's see, what I do when you ask my process A to create this file is >) to have a program B sitting around that is setuid/setgid to whomever >) I want you to think A is; ... > >If you have this program B, you can impersonate your victim completely. >Why not just assume that you have your victim's password? It comes >to the same thing. In versions of UNIX with which I am familiar, you need no permissions of any kind on a file to make new links to it. So if there are setuid files owned by root on the same filesystem as the directory where the client process is supposed to create the setuid file, then any random user can impersonate Mr. Root. Maybe a server can securely verify the userid of a client by requiring the client to create a setuid file with name *and* *contents* specified by the server? -- I am not David Canzi, my name is.
jfh@rpp386.UUCP (John F. Haugh II) (07/23/88)
In article <4909@watdcsu.waterloo.edu> dmcanzi@watdcsu.waterloo.edu (David Canzi) writes: >Maybe a server can securely verify the userid of a client by requiring >the client to create a setuid file with name *and* *contents* specified >by the server? >-- >I am not David Canzi, my name is. or perhaps, require the file be created with only one link? and with a current last file modified/accessed/inode-changed collection of times? - john. -- I don't live in a desert, my name does ;-) -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
daveb@llama.rtech.UUCP (Dave Brower) (07/26/88)
In article <51@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >In article <3789@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: >> In article <2310@rtech.rtech.com> I start this off: >> >How can the server find out who the client is, in a spoof-proof and >> >secure way? On BSD, one can have the server ask the client to create a >> >randomly-named file, and the server can see who the owner of the file >> >is. On SV, this fails because the client can chown it to be anyone >> >else. (The same is true of msgs and shm segments). >> > >> >Oh wise and knowledgeable Wizards, what is a Way? > >> have the client create a file with the suid and sgid bits set. you >> can't chown a file after setting those bits without having some of >> them cleared. the documentation for chown(2) specifies that the SUID >> and SGID bits are cleared if either owner or group are changed. > >Let's see, what I do when you ask my process A to create this file is >to have a program B sitting around that is setuid/setgid to whomever >I want you to think A is; A would start up B as a subprocess, with the >desired filename in argv[1]; B would create it. How would you determine >that A isn't this uid/gid combination? That would suit my purposes just fine, and in fact I want to support suid/sgid programs. If you've got a program B that is suid/sgid that can do things for you, then you can have it make your program A suid/sgid to that other user as well. I which case, you don't really need B for very long... This isn't the server's problem. It is a problem for the person to whose uid you have usurped. Unless root sweeps for unauthorised suid/sgid programs, there is not much the other user can do about it. -dB "Ready when you are Raoul!" {amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!