Subject: Re: Systrace policy fingerprints? (Re: finer grained IPNOPRIVPORTing)
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: Daniel Carosone <email@example.com>
Date: 05/27/2005 20:18:00
Content-Type: text/plain; charset=us-ascii
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 :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)
-----END PGP SIGNATURE-----