>   Q: So, how do you stop the list being updated later?
   >   A: by using securelevel - the fingerprints can only be loaded at
   >      securelevel == 0.  The full effect of the verified exec is in
   >      effect at securelevel > 2 (i.e. 3 onwards), at this point warnings
   >      about invalid/missing fingerprints become fatal errors, before this
   >      they were merely warnings.
   >
   >i assume that is "securelevel <= 0" ?
   
   prolly, but the "securelevel > 2" bit gives me pause.  why not just
   "securelevel > 1"?

indeed.  securelevel > 2 has never been defined before?

      
   >   Q: Doesn't chflags(1) do all this already?
   >   A: Not really.  It can be used to do some of the work but there are
   >      some things it cannot do like prevent a file from being executed
   >      nor can it give any confidence that what you are executing has not
   >      been tampered with.
   >
   >how does it not give you confidence it has not been tampered with?
   
   because now tampering with the underlying filesytem is evident,
   whereas chflags doesn't protect you against that?


i guess in the SAN situation i might buy this... but in the local
situation, if this happens, it's either a bug or a local (physical)
problem that we can't avoid.  i don't see how veriexec makes this
inherently more secure.  it probably has some nicer benefits over
chflags, but nothing that should increase/decrease real security.
(i'm sure that together they "raise the bar" further than either
does individually.  also rasies the annoyance bar a lot further as
well i'd guess :-)


.mrg.