In comp.unix.bsd.openbsd.misc Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
> jKILLSPAM.schipper@math.uu.nl wrote:
>> In comp.unix.bsd.openbsd.misc Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
>>> Karen Hill wrote:
>>>> Stefaan A Eeckels wrote:
>>>>> On 1 Sep 2006 12:28:12 -0700
>>>>> "Karen Hill" <karen_hill22@yahoo.com> wrote:
>
>>>>> But root can unset the immutable flag.
>
>>>> Not when they are at a networked run level according to the OpenBSD man
>>>> page on the subject. They would have to reboot, or bring it down to
>>>> single user mode to do that.
>
>>> Do you mean they'd have to reboot to do it at all, or do you mean that
>>> they'd have to reboot to do it in a supported manner? I strongly
>>> suspect it's the latter. After all, at some level, it's all bits and
>>> bytes (both on disk and in RAM), so if you can execute privileged
>>> instructions on the processor, you can do whatever you want, period.
>
>> I am not currently aware of any way to change the runlevel from a
>> running OpenBSD system - by design, root cannot execute kernel-level
>> ('priviliged' in your message, I believe) code.
>>
>> One of the ways of doing this is denying access to kernel memory - see
>> mem(4), securelevel(7) on a OpenBSD system.
>
> Well, that's a very different kind of root than what I'm familiar with,
> but I suppose you could do it that way.
>
> I guess this means that if you try to go this route, you have to worry
> about loadable kernel modules. Solaris, of course, has them and depends
> heavily on them. Perhaps one solution to this is to make the entire
> tree of kernel modules (including all the directories) immutable as well.

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.

Also, OpenBSD's kernel is not very modular - there is a module
framework, but almost everything is compiled straight into the kernel.
Only in rare circumstances do you actually load any modules - for
instance, the OpenAFS port needs a kernel module. But that's the only
one I ever needed.

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

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

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

Joachim