>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

Thor's idea sounds cool.
I'm alraedy planning to add the ability to use veriexec to pass flags 
that would find their way into the proc struct - at exec time.  

>Hmmm do you mean use veriexec to ensure the policy files are not
>modified and only load files that have veriexec fingerprints loaded?

I assumed he meant something like what I described above - ie. using the 
veriexec check at exec time to force some feature - as described in the 
flags passed to veriexec during fingerprint load.

>If you do then Elad may have already done what you need - part of what
>he has done recently was add some sysctl knobs that give finer grain
>control over veriexec - one of those knobs (the "strict" knob) can be
>set such that files without fingerprints cannot be read.

Hmmm, that doesn't sound particularly useful, wouldn't that mean that every 
file needs a fingerprint and thus becomes immutable?

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

>I actually did have a look at doing this* but, unless I am mistaken,
>this means dragging into the kernel a whole bunch more crypto stuff.
>One alternative is to do the signature verification stuff at the
>userland and pass in a struct to the kernel that indicates the
>fingerprint was signed.  The big assumption with this is that the
>fingerprint/signature loader has not been subverted (or replaced or
>someone running some rogue code) in such a way as arbitrary data can
>be passed into the kernel.

As I've said before, I don't like the idea of pulling RSA and similar
stuff into the kernel.  I'm using detached signatures on the fingerprint
manifests, and using a loader that won't proceed unless it can verify 
the signature.  You could easily have it tag the structs passed to the kernel
with an id of the signer (I only have one signer of course), doing this
in userland allows maximum flexibility.  The only way the loader can be 
compromised is if verexec doesn't work ;-).  Preventing PTRACE on the loader
process or anything else involved in signature verification helps a lot.

--sjg