DragonFly kernel List (threaded) for 2006-09
Re: Cache coherency, clustering, and Kernel virtualization
:Virtualization serves as a crude but effective way to accomplish the
:former, but not the latter. That a constrained subprogram should not be
:allowed to adversely affect its container is important -- indeed it is
:something that we should be able to take for granted these days. But to
:use the existence of such a capability to justify the underengineering
:of the security of the systems which run beneath; is disconcerting, to
:the say the least.
:I am not opposed to the concept of allowing the kernel to run in
:userland or of virtualization generally. It would great for a BSD
:to finally have that capability. But it doesn't make it okay to allow
:vulnerabilities in any system -- virtualized or otherwise, clustered or
:otherwise. If your clustered system is not something that you could
:trust as your main OS, I would think twice about deploying any such
:system to a public network.
I wouldn't call it crude. I would call it effective.
There is a very simple way to think about security in a software system.
It is simply: The less code you have running outside your security
abstraction(s), the more secure your system is. That's it.
A user process context is a black box. Nothing inside it can get out
except through a page fault, trap, or system call. The page fault,
trap, or system call represent choke points. If all the real kernel
does is take those choke points and pass the data to the virtual kernel
instead of trying to process it, then the amount of code one must write
to serve that necessary function is fairly minimal and can arguably be
made quite secure.
The virtual kernel running as a user process is another black box, in
another sandbox. Since this user process is able to talk to the real
kernel through hundreds of system calls and code paths, it is
considerably less secure -- not much more secure then a normal user
process running as NON-root would be, but still considerably more
secure then allowing the related services to run under the real kernel.
From the point of view of the real kernel we now only need to audit
a single program, the virtual kernel, to protect ourselves from it and
everything running under it. Securing a single program is arguably far
easier then securing the ten different services that have been
virtualized under that program.
Consider the types of security failures we see out in the field... nearly
all such failures exploit code bugs that allow a security barrier to
be breached. For example, a system call might have a bug that allows
an unprivilaged program to write to kernel memory. An encryption
algorithm might have a buffer overflow. A JVM's byte code interpreter
might have a bug that allows a java program to break out of its sandbox.
An external API might not properly check arguments passed to its
functions. It is nearly impossible to secure millions of lines of code.
It is far easier, however, to lock those million lines of code into
a sandbox and secure the choke points that lead out of the sandbox.
There is no way around this basic truth.