>>    prolly, but the "securelevel > 2" bit gives me pause.  why not just
>>    "securelevel > 1"?
>> 
>> indeed.  securelevel > 2 has never been defined before?
>
>I looked at this just before I did the merge.  Securelevel > 2 IS used
>but it is not documented as far as I can tell.  The sysctl code has a
>check for securelevel > 2 in the code path for changing the core file
>name for a process.  On that basis I left my stuff as going totally
>anal at securelevel > 2.  I was quite prepared to change the code to
>do this at securelevel > 1, it is not a big deal.

actually, given the other securelevel uses in the kernel (which i
think someone ought to clean up), i suspect that that's an error.

>> 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.
>
>As I said, it gives a verification that what you think you are running
>is what you are running, it is about ensuring the integrity of the
>trusted computing base.  Chflags can prevent files being modified but
>it cannot tell you if it was tampered with as some stage before the
>flags were applied.

...and it also can't tell you if the raw disk was frobbed out from
underneath you.  chflags protects things at the ffs layer.  if you go
below that, all bets are off.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."