>> Just to clarify, I meant that you could not (by any means) make a
>> file executable while the system is running at whatever secure-level
>> turns your feature on and you clear execute permissions when a file
>> is written to.

> This brings up an interesting point.  We probably should take
> features like this and make them one-way sysctls, so that there isn't
> too much assumed about what's in a `securelevel'.

Thank you.  Something had been bothering me about this, and now that
you mention it, this is it: way too much is getting rolled into a
single securelevel setting.  Maybe I want a couple of features from a
high securelevel without some others that kick in at a lower
securelevel....

> In fact, I'd venture to suggest that much of the current
> `securelevel' functionality would be better implemented by sysctls
> that are one-way settings (reset only at reboot).

> Or, there could be a `securelevel' with exactly two states (0 and 1),
> where `0' indicates two-way security switch sysctls, and `1'
> indicates one-way settings.

...and of course kern.security.securelevel would itself be one-way
(arguably with the exception of init, though if init has any special
rights, it should also be immune to ptrace() and moral equivalents).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B