On Thu, May 26, 2005 at 07:14:52PM +1000, Daniel Carosone wrote:
> On Wed, May 25, 2005 at 10:11:53AM -0500, Eric Haszlakiewicz wrote:
> > If you always need to run the systrace binary, how does that help
> > get rid of setuid binaries if, in order to enable the privilege elevation,
> > you need to be root to start with?
> 
> There are a number of ways, one already pointed out.  For the original
> purpose described (daemons binding sockets) they're typically started
> from rc scripts (or inetd) as root, and systrace can invoke the
> program as some other user via -c.

There are some rough edges in this area of systrace -- or perhaps in my
knowledge of it.  One thing that comes to mind is "let the user run a
one-line (conceptually, anyway) setuid program that execs the program
you want to run with elevated privilege".  Since systraced status
inherits across execs unless the policy says otherwise, you ought to
then be able to write a policy that allowed bind of a specific port
"as root" and all other syscalls the program does "as $USER".  Except
that that won't quite work because the setuid followed by exec will
lose the original userid.  Oops.  Also, how do you force the user to
run the original program systraced (or allow him to only run it
systraced)?  You could run his shell under systrace, but that is
rather extreme and you will still trip over the first problem.  At
the moment the only way I see out of this is to make the setuid
program explicitly call /bin/systrace -c, which is an annoying kludge.

I can think of an _elegant_ way to solve this, involving combining
veriexec and systrace, with some minor tweak to allow setuid operation
(perhaps, since root would have to load the fingerprints of all the
systrace policies into the kernel, in this case systrace should _always_
behave as if invoked by root with -c uid of the actual invoking user).
It's just a simple matter of time to write the code -- and I do *not*
have that; I am buried in ancient Greek and will be for the next two
months.

However, if you think about the possibilities, I think you'll see what
a powerful combination it would be.  For example, in the future, if
veriexec knew about signatures instead of just fingerprints, one could
associate default policies with executable signers... and for right now,
just the basic mechanism (no signatures, just systrace fingerprints in
the kernel, policies treated as if systrace were invoked by root) would
solve your problem, which is a common one, in a really neat way.

Thor