From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934102Ab3ICXua (ORCPT ); Tue, 3 Sep 2013 19:50:30 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:33611 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761447Ab3ICXu2 (ORCPT ); Tue, 3 Sep 2013 19:50:28 -0400 From: Matthew Garrett To: linux-kernel@vger.kernel.org Cc: linux-efi@vger.kernel.org, keescook@chromium.org, hpa@zytor.com Subject: Date: Tue, 3 Sep 2013 19:50:07 -0400 Message-Id: <1378252218-18798-1-git-send-email-matthew.garrett@nebula.com> X-Mailer: git-send-email 1.8.3.1 X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 2001:470:1f07:1371:6267:20ff:fec3:2318 X-SA-Exim-Mail-From: matthew.garrett@nebula.com X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We have two in-kernel mechanisms for restricting module loading - disabling it entirely, or limiting it to the loading of modules signed with a trusted key. These can both be configured in such a way that even root is unable to relax the restrictions. However, right now, there's several other straightforward ways for root to modify running kernel code. At the most basic level these allow root to reset the configuration such that modules can be loaded again, rendering the existing restrictions useless. This patchset adds additional restrictions to various kernel entry points that would otherwise make it straightforward for root to disable enforcement of module loading restrictions. It also provides a patch that allows the kernel to be configured such that module signing will be automatically enabled when the system is booting via UEFI Secure Boot, allowing a stronger guarantee of kernel integrity. V3 addresses some review feedback and also locks down uswsusp.