Subject: Re: Sysctls vs. securelevel (was Re: Volunteers to test some kernel
To: None <>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 06/15/1999 10:55:38
>> 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

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

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B