Message-Id: <E1HI5AB-0000rZ-32@be1.lrz>
Date:	Fri, 16 Feb 2007 16:38:18 +0100
From:	Bodo Eggert <7eggert@....de>
To:	Roman Zippel <zippel@...ux-m68k.org>,
	David Howells <dhowells@...hat.com>, 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

Roman Zippel <zippel@...ux-m68k.org> wrote:
> 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.

Hardening a system should include deeper layers, too.

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

Off cause there are other ways to expose the kernel, but they can be plugged,
too, one by one. You wouldn't leave your door open just because your window
is open, while leaving the window open because the door is open.

> The simple verification can also be done in userspace and

You may verify in userspace, but you can't use the result.

OTOH, having 1000 lines of code to verify a module _is_ bloat for this task.
Remove a 0 and it should be plenty (not counting the help text).

> module signing offers no real security.

It offers security against a class of attacks.

> What real value do these patches provide, that can't be reached via other
> means?

It provides an extra layer of security: If an exploit allows execution of
insmod(userstring), it can't compromise kernel internals.

> Who else than distributions would be interested in this?

How large is the userbase _not_ using a distribution? And are they unable to
unselect [X] Signes modules support?

> Pretty
> much any use you initially mentioned can be done in simpler ways, e.g.
> anyone afraid of modules simply disables module loading completely.

That would work if there was no need for modules. Unfortunately some people
are doomed with external modules, or not experienced enough to customize
their system. Those could benefit from a sysctl(?) saying "unsigned_modules
= taint|disallow".
-- 
Whenever you have plenty of ammo, you never miss. Whenever you are low on
ammo, you can't hit the broad side of a barn.

Friß, Spammer: 5usmqnrkze@...Mz.7eggert.dyndns.org
-
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/

Powered by blists - more mailing lists