Antonomasia <antnotatla.demon.co.uk> wrote:
> From: "Len Budney" <lbudney-lists-auditnb.net>
>
>> 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).
>
> I fail to see the contradiction (as a result of not having done this ?).

By ``wrapper'' I mean that no modifications to the callee are allowed.
So I want to deny execute permissions on the callee to everyone but
(for example) root, and probably move the callee to /usr/protected/bin,
but otherwise leave the callee unchanged.

The wrapper then (1) does something useful, (2) drops privileges, and
(3) calls the protected program.

Unfortunately, (2) and (3) conflict, because (2) can't be done after an
exec(), and (3) can't be done after (2).

The semantics of the imaginary fexec() would be unchanged from the rest
of the exec() family. In particular, the close-on-exec flag would be
honored, setuid bits on the wrappered program would be honored, etc.

One example of such a wrapper might be a program which checks the
environment and arguments for a specific buffer overflow before
calling the protected (presumably setuid) program. This could be used
as a temporary measure if an overflow bug is announced, but no fix is
available yet because the bug responsible is subtle. The stopgap fix
is then (1) chmod 700 the affected program, (2) move the affected
program (to an assumed known location), and (3) replace the affected
program with a script calling ``wrapper args program''.

Len.

--
Three cheers for frivolous OS incompatibilities!
		                -- Dan Bernstein

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