On Thu, May 26, 2005 at 09:08:50AM -0400, Thor Lancelot Simon wrote:
> 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.

Privilege elevation works only if the privilege to be given away is
available somehow.  The easiest way of getting this done was to have
Systrace executed as root.  There are several ways of doing this. I
always imagined a single setuid binary to which all original setuid
binaries would be symlinked.  The wrapper would then start the binary
under the correct user with the right policy.

> 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.

Those would all be good extensions if we wanted to invest in the
necessary kernel magic.  The privilege needs to come from somewhere :-)

Niels.