> after reading the recent CORE advisory about the mbuf handling bug, I
> was wondering if some of OpenBSD's exploit mitigation strategies could
> also be applied to the kernel in order to prevent exploitation of kernel
> bugs. Theo's presentation about exploit mitigation (
> http://openbsd.org/papers/ven05-deraadt/index.html ) mentions Stackgap,
hard to do in the kernel
> ProPolice/SSP,
already done in the kernel
> W^X/NX bit,
NX is just one particular machine's method for implimenting
a SUBSET of W^X, so never compare NX in this way. We don't
go around talking about the X-bit in that way, when 5 architectures
have a X-bit in the PTE. In any case, W^X is much more than
that -- it is like having a plan to end poverty, instead of
giving one man a cup of rice. W^X is a policy applied to the
address space, and a X or NX bit is part of the mechanism. The
mechanism's don't matter.
some of our architectures already partially follow the W^X
principle in the kernel.
> ld.so randomization,
there is no ld.so in the kernel
> randomized malloc,
very hard to do in the kernel
> .rodata segment,
already done in the kernel
> StackGhost (on Sparc/Sparc64),
extremely difficult to in the kernel
> privilege revocation/separation,
split the kernel? huh?
> which all seem to have been introduced in order
> to protect buggy userland code from being exploited (please correct me
> if I'm wrong).
There may be other things we can do in the kernel that are not like
userland.
But the kernel is not like userland. It does not work the same way,
at all. We'll do what we can, but over-simplifying the problem like
you are is just crazy.
> Are there any known techniques for also protecting kernel code, which
> could be implemented in OpenBSD, i.e., would it be technically feasible
> (or would it make any sense) to implement some address randomization to
> a kernel image after it has been initially loaded into memory? Does W^X
> also apply to kernel code, i.e., could it be applied in order to prevent
> maliciously introduced code from execution inside the kernel?
> In other
> words: is a bug-free kernel the only way to eventually render a system
> secure against such attacks? And if this is so, does this mean that
> microkernel designs are in fact inherently more secure than monolithic
> kernels, because they allow for a better reduction of the attack surface
> which can't be achieved with alternative strategies? In other words:
> regarding security, is Prof. Tanenbaum actually right with his
> preference for microkernels in his books about operating systems?
I don't think you know much about the kernel, and blindly following
something you read in one book actually makes it worse. Things are
much more complicated than that book claims, and you cannot go around
trying to simplify it like that.
