Re: Should we automatically generate a module signing key at all?

[Andy Lutomirski]

On Tue, May 19, 2015 at 10:32 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 2015-05-19 at 11:55 -0400, Theodore Ts'o wrote:
>> On Tue, May 19, 2015 at 04:30:17PM +0100, David Howells wrote:
>> > We do have to allow people to load external modules.  Yes, you could argue
>> > that you should just disable all your security systems if you want to do
>> > that...
>>
>> Is module signing really meant for distro kernels, or would anyone
>> besides people creating distro kernels care about this?  I thought I
>> saw some messages (including from Linus) that the "common case" is the
>> average kernel developer who creates a throw-away key, uses it to sign
>> all of the modules in the kernel build, and then throws it away.
>>
>> I wouldn't know, because I don't use module signing at all, and I
>> don't really see the point.  I build my own kernels for my own use,
>> which means either modules for my own developer convenience, or if I'm
>> building it for a server where I really care about security, I'll
>> build in exactly the drivers I need and disable modules entirely.  So
>> I'm clearly not the intended use case, either as a distro kernel
>> release engineer, or as a "build a kernel with modules and then throw
>> away the key use case".
>>
>> So I'm really curious --- are there significant numbers of people
>> doing kernel builds, besides distro kernel engineers, who would use
>> module signing?  If so, them sure, let's spend time optimizing so that
>> it's really easy for those folks.  If not, maybe it's simpler just
>> make things easy for people who will be storing the key in some
>> external hardware device, and just be done with it.
>
> I assume you're signing your kernel images.  Remember the Yubikey NEOs,
> given out last year at the kernel summit, they can be used to sign the
> kernel images and with David Woodhouse's patches sign the kernel modules
> as well.

If it weren't a giant PITA, I would consider enabling module signing,
but I don't see much point on my system since I don't have secure boot
and I think it's misguided that kernel mode code should be considered
more important to protect than fully privileged user-space code.  I
think that managing the integrity of the filesystem as a whole is much
more important and indirectly protects modules as well.

The remaining thing to protect is the kernel image itself and whatever
trust in the filesystem is rooted in.  The kernel image could be
protected by secure boot or by a TPM that would prevent filesystem
access if the kernel hash is wrong (assuming that the BIOS has usable
TPM support -- TXT would be even better, but it's dangerously broken
on my system).  The filesystem could be protected by a key of some
sort baked into the kernel image.

Keep in mind that, for a normal mutable desktop system, there's no
reason at all to use asymmetric crypto to protect the filesystem or
root block device.  The running system needs to be able to *modify*
the image, so it would need the private key.  This means that
symmetric crypto would be a better choice.

For an atomic system, if the kernel is longer-lived than the root fs
image then we need some way of verifying a root fs image that isn't
rooted in a hash baked into the kernel image.  If they have the same
lifetime, then it makes little difference.

Nonetheless, I think this is all irrelevant to the present discussion.
The sane way to verify modules on an IMA or other integrity-protected
/lib/modules fs is using finit_module.  If that's not available *and*
a user wants to protect kernel mode against root, then the user needs
some kind of module verification.  Both the secure boot compliance use
case and the kernel developer running 'make' with forced verification
use case are IMO quite nicely covered by a hash tree, and using a hash
tree allows deterministic builds and makes the build process cleaner.

If someone wants to deterministically build an entire OS (kernel,
modules, initramfs, and root fs), then a hash tree works for all of
it.  If some authority is needed to verify updates, then that
authority can use asymmetric crypto.

--Andy
--
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/