Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.misc -> OpenBSD and Solaris (was: Tough question for oracle DBAs/Solaris Admins. Log shipping.)
In comp.unix.bsd.openbsd.misc Casper H.S. Dik <Casper.Dik_at_sun.com> wrote:
> jKILLSPAM.schipper_at_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.
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'.
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).
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.)
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 Received on Mon Sep 04 2006 - 16:19:14 CDT