Re: [PATCH 0/6] MODSIGN: Kernel module signing

[David Howells]

Roman Zippel <zippel@xxxxxxxxxxxxxx> wrote:

> > Now, this is not a complete solution by any means: the core kernel is not
> > protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> > controls) one relatively simple attack vector.
> 
> This is really the weak point - it offers no advantage over an equivalent 
> implementation in user space (e.g. in the module tools). So why has to be 
> done in the kernel?

Because the init_module() system call is the common point of module submission
to the kernel, not any particular userspace program.  There is no requirement
for userspace to load a module by invoking a module tools program or library,
and so userspace can bypass the checks entirely by just calling init_module().
Assume for a moment that you can't trust userspace...  (Obviously, if you can't
trust the kernel then you're already stuffed.)

It is possible to protect /dev/mem and /dev/kmem or make them unavailable and
it is possible to protect the kernel's memory whilst it is running (provided
you don't have nommu or broken hardware and you don't let userspace concoct any
DMA request it likes) which mostly closes those other vectors I mentioned.
This isn't something I intended to look at with this patch.  Those are separate
holes.

Making the core kernel load image inaccessible or immutable to root is not
something I can provide a generic solution for and security checking the core
kernel load image has to be done at an earlier layer as you can't rely on
something guaranteeing its own integrity because if someone can alter that
something, then they can bypass the self-checking too...

However, modules permits arbitrary modification of the running kernel to be
attempted.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/