vlcek@mit-caf.MIT.EDU (Jim Vlcek) (07/26/89)
I would like to design a simple server to help automate a signup/signoff type of scheduler. This would involve accepting requests for a certain resource to be allocated to a user on a specified date, checking to see that the target date is open, and allocating it if it is. Conversely, the signoff procedure would check the specified date to see that it is allocated to the user seeking to sign it off, and deallocate the date if so. I'm working under 4.3BSD, and using sockets to connect the server to the signup/signoff clients. This avoids giving write access to the schedule file to all qualified users (with obvious security problems!), as would be necessary in the absence of a server. What I'd like to know is: how can I verify the identity of a client seeking to sign off? This is to say, how can I keep someone from creating a bogus client which falsifies it's owner's ID in order to sign other users off? I don't know of any way to determine the pid of the process at the other end of a socket -- is there any? Or should I deny write access to the socket to all but its owner, and run the client programs setuid? Jim Vlcek (vlcek@caf.mit.edu uunet!mit-caf!vlcek)
guy@auspex.auspex.com (Guy Harris) (07/27/89)
>What I'd like to know is: how can I verify the identity of a client >seeking to sign off? This is to say, how can I keep someone from >creating a bogus client which falsifies it's owner's ID in order to >sign other users off? I don't know of any way to determine the pid of >the process at the other end of a socket -- is there any? No. Given that, in general, the "process at the other end of the socket" may not even *have* a PID - for example, MS-DOS doesn't have processes, much less PIDs - it's not surprising that there's no way to determine the pid.... Furthermore, even in the case of UNIX-domain sockets, there isn't necessarily a single "process at the other end of the socket" - a socket is represented by a file descriptor, and a process can pass them on to children (or even to unrelated processes over UNIX-domain sockets). >Or should I deny write access to the socket to all but its owner, and >run the client programs setuid? That's one way of doing it. Of course, if you do that, and the sockets are UNIX-domain sockets (as the comment about denying write access implies), you could have the client run with a user or group ID with write access to the schedule file, and not bother with the server.... Another way might be to use some mechanism such as Kerberos, and require the client to provide some sort of validated cookie to prove who they are.
Sandeep Mehta@bebop (Sandeep Mehta) (07/27/89)
In article <2293@auspex.auspex.com>, guy@auspex (Guy Harris) writes: > >Another way might be to use some mechanism such as Kerberos, and require >the client to provide some sort of validated cookie to prove who they >are. Yup, using a proven authentication protocol, such as Kerberos, seems to me to be the best way to go. Using a encyrpted key you can do correct authentication in at least 4 or more encryptions+decryptions. Kerberos reaches authentication at the cost of synced clocks (if clients/servers are across machine boundaries) because it is time-stamp based. I don't know the performance degradations of using correct authentication in your application but with >= 4 encrypts+decrypts it's probably non-trivial. sandeep -- Sandeep Mehta ...to be or not to bop ? uunet!philabs!bebop!sxm sxm@philabs.philips.com
larry@macom1.UUCP (Larry Taborek) (07/28/89)
From article <2293@auspex.auspex.com>, by guy@auspex.auspex.com (Guy Harris): >>What I'd like to know is: how can I verify the identity of a client >>seeking to sign off? This is to say, how can I keep someone from >>creating a bogus client which falsifies it's owner's ID in order to >>sign other users off? I don't know of any way to determine the pid of >>the process at the other end of a socket -- is there any? > > No. Given that, in general, the "process at the other end of the > socket" may not even *have* a PID - for example, MS-DOS doesn't have > processes, much less PIDs - it's not surprising that there's no way to > determine the pid.... [some stuff deleted] Gee, I don't know much about sockets, but why couldn't you, when you fork the child, have the first packet exchanged hold some sort of validation information. Say the password of root of both machines is traded between both machines, and verified in a table local to each. If they verify that they have a good connection, then normal communications starts up. Otherwise, log files are written to, bells sound and the communications session is terminated. Of course, the verification information could be ANYTHING, and not necessarily passwords. Hope this helps... Larry -- Larry Taborek ..!uunet!grebyn!macom1!larry Centel Federal Systems larry@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 703-758-7000