Re: [PATCH 0/10] Add additional security checks when module loading is restricted

[Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>]

On Wed, 2013-08-28 at 18:58 -0400, Lenny Szubowicz wrote:

> I'm root. So I can write anything I want to the swap file that looks
> like a valid hibernate image but is code of my choosing. I can read
> anything I need from /dev/mem or /dev/kmem to help me do that.
> I can then immediately initiate a reboot.

No, you're blocked from /dev/mem and /dev/kmem. That doesn't make it
impossible, but it does make it much harder. A more realistic attack is
to write something that looks like (but isn't) a hibernation image which
effectively jumps back into the resume kernel after modifying it, but
you'd still need to generate a bunch of kernel state.

The need for a reboot makes it a less significant attack than the others
that this patchset protects against, which all allow the modification of
the already running kernel. If you also want to protect against attacks
involving reboots then you need to secure the on-disk representation of
the kernel as well, which means Secure Boot, and that also means you
want encrypted hibernation support.

If you need something for the short term then I'd suggest just adding a
config option that disables hibernation when a system is in Secure Boot
mode, but the best plan is pretty much to review the encrypted
hibernation patches that got posted recently. It'd be easy to tie those
into appropriate policy.
-- 
Matthew Garrett <matthew.garrett@nebula.com>