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

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]

Date:	Wed, 28 Aug 2013 23:05:51 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	Lenny Szubowicz <lszubowi@...hat.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"jwboyer@...hat.com" <jwboyer@...hat.com>,
	"keescook@...omium.org" <keescook@...omium.org>
Subject: Re: [PATCH 0/10] Add additional security checks when module loading
 is restricted

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@...ula.com>