If you get to change the problem slightly I can think of various
"solutions."

For instance, if you can turn the thing-to-be-wrapped into a dynamic
library, couldn't you use dlopen? Ie, as the priv'd user, dlopen the
library, drop privs, and call into the shared library. I'm not all that
smart about stuff like dlopen, so I don't know if you could rename the
thing-to-be-wrapped's main() to something else and that'd be it, or if
it's more involved than that.

Also, perhaps you can take advantage of the file-descriptors
stay-open-across-exec stuff. (Again, this is a slightly-modify-the-source
of the 2-b-wrapped thing.) You have a file (path probably hardcoded into
the binary) that mortals can't open, and yet if this app finds itself
started up with that file sitting open on a pre-determined file
descriptor, it knows it was called via the wrapper. (Hmm, this won't work
on any system like linux/x86 where it's impossible to have
executable-but-not-readable binaries, because they could copy the binary
and hexedit to jump past the check.)

Hmm, interesting challenge. =)

jim
sure he's showing his ass on this one =)

On Mon, 14 May 2001, Len Budney wrote:

> Hello,
>
> I'm interested in wrapping a program such that (1) users cannot run
> the program without the wrrapper, and (2) the program ends up running
> with the uid/gid of the caller.
>
> The problem is that (1) seems to imply a setuid wrapper, with special
> privilege to run executables in some directory, and (2) implies calling
> {setuid(getuid()); exec(...);}, which of course contradicts (1).
>
> One solution is a new syscall, fexec(int fd, char *argv[]); I can then
> make the setuid program call {fd=open(); setuid(getuid()); fexec(...);}
> which meets both criteria above.
>
> Is there a real solution which doesn't involve implementing a new system
> call?

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]