Re: suidpid( UID, credential? ) ? secure IPC?
kwrohrer@enteract.com
Mon, 6 Oct 1997 01:20:58 -0500 (CDT)
And lo, Jim Dennis saith unto me:
> I was wondering if there is any mechanism for having some
> process (a daemon or kernel module perhaps) "touch" a process
> and set its *real* UID to a different value.
Probably not.
> Would it make sense to add a suidpid() call?
What happens if, after authentication, the process dies and another
process pops up with the same PID? Hard to do nowadays, but I don't
believe it's guaranteed impossible, especially given some way of
bogging the authenticator down at the right moment...
> This would be a privileged system call that would allow a non-privileged
> program to request an suid change through any IPC mechanism we'd like
> to allow it to use.
If a privilege-requiring program is written correctly, it can be started
with privs and will get rid of them as appropriate. If it's written
incorrectly (e.g. vulnerable to buffer overrun compromise) it can use
this mechanism to gain privs anyway.
> Imagine running popd, ftpd, login, su, sudo as "nobody" with no
> SUID bits and having them talk to some sort of "setuserd" daemon --
> passing their request and credentials to them through ???? (some secure IPC).
> Then having the "setuserd" (or whatever we'd call it) able to grant that
> request.
Imagine running popd, ftpd, login, su, sudo written correctly. :-)
> What would be a suitably secure IPC mechanism? We'd want this setuserd
> or reference monitor to be able to "register" itself with the kernel
> in someway -- to keep the actually authentication in userland but without
> creating a hole whereby some random program could try to "become" the
> authorisor.
What, you want the authenticator not to require privs either? Yeesh.
> If we had all that -- could a similar method be used to request access
> to other privileged system calls or to other resources. Could we have
> a mechanism where the requesting programs essentially says:
>
> I'd like this sort of access (read, write, append, execute)
> to this file -- here's a "capability" or "token" for it.
>
> ... and have some other process authorize the access and grant the
> access.
>
> If we had a few primitives of this sort we might be able to have a
> full featured "capabilities" subsystem running under Linux -- in such a
> way as to permit many normal programs to run, unmodified, with the help
> of some small wrappers.
What "normal" programs need capabilities?
Keith