Subject: Re: Sysctls vs. securelevel (was Re: Volunteers to test some kernel
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
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 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).
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B