--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 26, 2005 at 09:08:50AM -0400, Thor Lancelot Simon wrote:
> I can think of an _elegant_ way to solve this, involving combining
> veriexec and systrace, with some minor tweak to allow setuid operation
> [much elided]

I like these ideas.  I especially like the idea that there be a
certificate for each executable with not only an authenticated hash
for veriexec, but also other policy about its execution.

Other platforms (Windows, Java, ...) have signed executables, and
separate policies about what executables or signers are allowed to run
or do; that can work well, but there's always the potential for attack
against the policy configuration rather than the signature.

So, continuing Thor's "in the future" musings:=20

  If we look at detached signatures (as we've started to do with
  veriexec fingerprints), we should look at ways to exploit that
  detachedness and allow that document to certify other policy things.

  I envisage that the 'program' to be executed (ie, in the users
  $PATH) would in fact be the certificate, to be parsed (and
  validated) by a new exec handler (alongside the ELF, a.out, MACHO,
  #!, etc handlers).  Not all of this needs to be in the kernel; such
  certs could be fed to a 'certificate interpreter' or 'exec policy
  server' in much the same way that shell scripts are.  It does need
  some extra mechanism, though - otherwise the original uid is lost,
  as Thor points out.

  The certificate would specify hashes and paths for the binary and
  for the systrace policy files, program and systrace invocation
  arguments, suidness permitted, extended acls for who can invoke the
  program, perhaps other stuff like appropriate rlimits, etc.

  (Note also that you might have multiple detached certs pointing to
  the same binary, with different policy, in such a scheme).

Some ideas for simpler hacks in the meantime:

  What about a file flag (ala schg etc) that indicates that the
  program should always be executed under systrace?  If the file is
  also setuid, then the systrace is executed as the setuid user, with
  -c to the original user. This could be combined with preloaded
  veriexec hashes (of both binary and systrace policy) as Thor
  suggests, and the combination could be made mandatory via an
  appropriate flag (securelevel?).

  /bin/systrace is setuid root. If the systrace *policy file* is
  setuid, it changes to that setuid user, and runs as if invoked with
  -c the original uid. In other cases, including where the program
  itself is setuid, it drops root and behaves as the original user
  exactly as if invoked without setuid.

These two achieve somewhat different, and perhaps complementary,
results.  I'm not sure which is closer to the original requirement,
because I'm not entirely clear what that was anymore :)

--
Dan.
--nFreZHaLTZJo0R7j
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFClvPYEAVxvV4N66cRAhJaAJ9pFGZwmztPakLHG5JWT0qhC83usgCglRf6
xjMkrlqpXQsoPHzu/8ckEow=
=jHIF
-----END PGP SIGNATURE-----

--nFreZHaLTZJo0R7j--