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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 15 Feb 2007 17:32:50 +0000
From:	David Howells <dhowells@...hat.com>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	torvalds@...l.org, akpm@...l.org, herbert.xu@...hat.com,
	linux-kernel@...r.kernel.org, davej@...hat.com,
	arjan@...radead.org, linux-crypto@...r.kernel.org,
	dhowells@...hat.com
Subject: Re: [PATCH 0/6] MODSIGN: Kernel module signing 

Roman Zippel <zippel@...ux-m68k.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/