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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Pine.LNX.4.64.0702151901380.14458@scrub.home>
Date:	Thu, 15 Feb 2007 19:33:52 +0100 (CET)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	David Howells <dhowells@...hat.com>
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
Subject: Re: [PATCH 0/6] MODSIGN: Kernel module signing 

Hi,

On Thu, 15 Feb 2007, David Howells wrote:

> > 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.)

All the security stuff in the kernel should provide the necessary means to 
restrict this system call.

> 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.

Exactly and as long as there are these holes, these patches are only 
kernel bloat. The simple verification can also be done in userspace and 
module signing offers no real security.
What real value do these patches provide, that can't be reached via other 
means? Who else than distributions would be interested in this? Pretty 
much any use you initially mentioned can be done in simpler ways, e.g. 
anyone afraid of modules simply disables module loading completely.

bye, Roman
-
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/