In comp.unix.bsd.openbsd.misc Casper H.S. Dik <Casper.Dik@sun.com> wrote:
> jKILLSPAM.schipper@math.uu.nl writes:
>
>>OpenBSD does not allow loading of kernel modules once the securelevel
>>has been raised above 0; this typically happens as part of the boot
>>procedure. This aspect of securelevels is actually quite useful.
>
> It is somewhat problematic for a kernel as Solaris where everything
> is rather dynamic; not being able to load the device driver for the
> PCI device you've just hotplugged is a bit awkward.

Well, OpenBSD probably wouldn't handle the hotplugging, anyway.

> Having the user immutability (which you can switch off) is useful in
> itself because it prevents accidental deletion and modification.

OpenBSD's rm(1) does warn you when trying to delete a file that is
either not owned by you, not writable by you, or probably meets a list
of other criteria I can't think of offhand.

Such protections are not extended to root, though - root is presumed to
know what (s)he is doing.

> In order to support hard immutability you can think of mechanisms like
> file signatures; as long as you load only pre-configured trusted modules,
> that is fine.

Well, as long as the kernel can be trusted to verify these signatures
correctly, if I understand you correctly. This is not a given.

>>This design actually makes a lot of sense; surely, modules can save a
>>small amount of memory, but it is usually not very significant. And it's
>>a rare occurence that even a Linux system loads a module once the system
>>is 'really up'.
>
> Not so on Solaris.

Really? While I think the ability to *do* this hotplugging is really
neat, I would imagine that - outside of hotswapping disks - this would
be quite rare.

Just curious - do you need this feature often?

>>Finally, note the aforementioned problem with immutable files - you can
>>always mount another file system over the parent directory (in OpenBSD,
>>obviously).
>
> Sounds like a bug.

A lot of people agree with you; Theo, though, thinks securelevels are
broken anyways.

Most probably, both camps are right.

>>This is not to say that root can't do truly nasty stuff; trojaning all
>>binaries and rm'ing the rest is pretty bad, for instance, and messing
>>with the bootloader is always good fun... (although securelevel 2 would
>>prevent that, but very few systems run at securelevel 2, as quite a few
>>things - notably, parts of the firewall subsystem like ftp-proxy - have
>>difficulty working. Plus, it isn't the default.)
>
> A lot of stuff becomes a lot harder when you can't change anything; for one,
> administration without endangering uptime.

Indeed, which is another reason why securelevel 2 is not used often.

However, if OpenBSD is deployed as a redundant firewall, uptime becomes
much less important, and securelevel 2 might make sense. Still, I would
most likely not use it.

Joachim