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

[Kees Cook]

On Wed, Aug 28, 2013 at 3:58 PM, Lenny Szubowicz <lszubowi@xxxxxxxxxx> wrote:
>
>
> ----- Original Message -----
>> From: "Matthew Garrett" <matthew.garrett@xxxxxxxxxx>
>> To: "Lenny Szubowicz" <lszubowi@xxxxxxxxxx>
>> Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-efi@xxxxxxxxxxxxxxx, jwboyer@xxxxxxxxxx, keescook@xxxxxxxxxxxx
>> Sent: Wednesday, August 28, 2013 6:41:55 PM
>> Subject: Re: [PATCH 0/10] Add additional security checks when module loading is restricted
>>
>> On Wed, 2013-08-28 at 18:37 -0400, Lenny Szubowicz wrote:
>>
>> > Did you purposely exclude similar checks for hibernate that were covered
>> > by earlier versions of your patch set?
>>
>> Yes, I think it's worth tying it in with the encrypted hibernation
>> support. The local attack is significantly harder in the hibernation
>> case - in the face of unknown hardware it basically involves a
>> pre-generated memory image corresponding to your system or the ability
>> to force a reboot into an untrusted environment. I think it's probably
>> more workable to just add a configuration option for forcing encrypted
>> hibernation when secure boot is in use.
>>
>> --
>> Matthew Garrett <matthew.garrett@xxxxxxxxxx>
>
> 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.

Strictly speaking, RAM contents are not available via /dev/*mem, even
to root. However, you can request a suspend image be written, but to
not enter hibernation. Then modify the image, and request a resume
from it.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/