Who dat?

Dave Brower daveb at llama.rtech.UUCP
Tue Jul 26 10:34:03 AEST 1988


In article <51 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>In article <3789 at rpp386.UUCP>, jfh at rpp386.UUCP (John F. Haugh II) writes:
>> In article <2310 at 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 at rtech.com <- FINALLY!



More information about the Comp.unix.wizards mailing list