re: set_his_uid()?

kwrohrer@ce.mediaone.net
Sat, 18 Jul 1998 15:29:06 -0500 (CDT)

And lo, Pavel Machek saith unto me:
>
> No. He asked us to add set_his_euid( pid_t pid, uid_t uid )
> syscall. I do not see why this syscall is bad idea.
>
> I'm not sure set_his_euid() syscall is bad idea. (Should be trivial to
> implement.) What do others think?
>
> PS: There is no problem with PID wrapping: application requesting
> server to suid here just must not die ;-). If she dies, she could
> easily do anything else (like chmod 666 /etc/passwd) after she is
> suid-ed.

Alas, "just must not die" is impossible to implement in user space.
By the time the authentication server decides that a petitioning
process is worthy of knighting, a malicious process may have already
slain the petitioner and taken its place. Hard to do, but made easier
by the fact that the load generated by enough fork()s to get the victim's
PID should slow down the authenticator...

Assuming the authenticator and petitioner communicate via some sort
of secure RPC (on the same machine as one another, natch)...would
something about UNIX domain SOCK_STREAM sockets stick around enough
to guarantee failure if the original petitioner dies? If not, would
POSIX allow it? Or could we define some cookie unique to each
process (PID . start_time should suffice?), that a process could
determine (unerringly) and pass to the authenticator, which would
use that cookie for set_his_euid(cookie_t *cookie, uid_t uid)?

Keith

-- 
"The avalanche has already started; |Linux: http://www.linuxhq.com     |"Zooty,
it is too late for the pebbles to   |KDE:   http://www.kde.org         | zoot
vote." Kosh, "Believers", Babylon 5 |Keith: kwrohrer@enteract.com      | zoot!"
 www.midwinter.com/lurk/lurker.html |http://www.enteract.com/~kwrohrer | --Rebo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html