From patchwork Tue Nov 5 20:35:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Seth Forshee X-Patchwork-Id: 1189918 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4771d444Z9z9sP4; Wed, 6 Nov 2019 07:35:18 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1iS5Xl-0003aN-DE; Tue, 05 Nov 2019 20:35:13 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iS5Xj-0003a9-Tp for kernel-team@lists.ubuntu.com; Tue, 05 Nov 2019 20:35:11 +0000 Received: from mail-yb1-f198.google.com ([209.85.219.198]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iS5Xj-0002FA-Lv for kernel-team@lists.ubuntu.com; Tue, 05 Nov 2019 20:35:11 +0000 Received: by mail-yb1-f198.google.com with SMTP id x191so6731430ybg.1 for ; Tue, 05 Nov 2019 12:35:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=BUaQZ8TpnPlM+xwyHIYTOmbyoB93P3ft3dKorHVfQaw=; b=cE9NQKnKYmYf+Smcxod7XATqlQJa08mhcsSIFcwtuu+I1yJZgoXGTHJOxvNLAgoy54 otj4WiBQmT62rEWnyrYZpsDpLz+8rX5abf7MqLfYKNk/AcDWbT7nEBlVeEDzRjU4miOz mu5X/gTFgS8I43hMetRTnlEcycMTjVH8bemlTiYMsfB30kJt4SDQMCad7ch5zqm1wyMH 67tJ5b4IS4y8sUruM4dWOeAJaw7Y8+n5z1dJaO29NEwoViycZZaHMbxgqXi7wBrrF68W lxN9xXa7o2NIs8wvj796SW3RpeX7qJtUWalEcHMOjPN8JOdagvssRH4rq7jcaZ65mv2+ Z1NQ== X-Gm-Message-State: APjAAAXS4M+x8BEqMNVdlBh0f27BwCy61kYRa6VaH25m+JJrofPOGdFE bQlKUHbkh9lKdCwopnruCGXebXZAtyJvvgGaH6ctCSvsm76UUmqXJi0KbHgknQmLc3FUFQLZHkK fWLV+slgendZpJCKJwqwXdyr+vDtd7u2aIDHRX5X54A== X-Received: by 2002:a81:304:: with SMTP id 4mr4800385ywd.324.1572986110476; Tue, 05 Nov 2019 12:35:10 -0800 (PST) X-Google-Smtp-Source: APXvYqzud3+5AwVHyI5gpbpgMnM+H8ehYTI8gw05jJfqw8OGVtBjA40O1MQMYVevxb7Vpv6QT+LTMw== X-Received: by 2002:a81:304:: with SMTP id 4mr4800372ywd.324.1572986110100; Tue, 05 Nov 2019 12:35:10 -0800 (PST) Received: from localhost ([2605:a601:ac3:9720:c5fa:bd86:e49d:5adc]) by smtp.gmail.com with ESMTPSA id s24sm8272543ywa.92.2019.11.05.12.35.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2019 12:35:09 -0800 (PST) From: Seth Forshee To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/1][SRU][B/D] UBUNTU: SAUCE: (efi-lockdown) Really don't allow lifting lockdown from userspace Date: Tue, 5 Nov 2019 14:35:04 -0600 Message-Id: <20191105203505.28634-2-seth.forshee@canonical.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191105203505.28634-1-seth.forshee@canonical.com> References: <20191105203505.28634-1-seth.forshee@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" BugLink: https://bugs.launchpad.net/bugs/1851380 "UBUNTU: SAUCE: (efi-lockdown) Add a SysRq option to lift kernel lockdown" adds a sysrq key to lift kernel lockdown, which is meant to only allow a physically present user to lift lockdown using a keyboard. However, the code has a bug which also allows root to lift lockdown through /proc/sysrq-trigger. Fix this bug to make this work as intended. Signed-off-by: Seth Forshee Acked-by: Tyler Hicks --- drivers/tty/sysrq.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c index 7c06541b422e..f72003937717 100644 --- a/drivers/tty/sysrq.c +++ b/drivers/tty/sysrq.c @@ -553,13 +553,13 @@ void __handle_sysrq(int key, unsigned int from) if (op_p) { /* Ban synthetic events from some sysrq functionality */ if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_SYNTHETIC) && - op_p->enable_mask & SYSRQ_DISABLE_USERSPACE) + op_p->enable_mask & SYSRQ_DISABLE_USERSPACE) { printk("This sysrq operation is disabled from userspace.\n"); - /* - * Should we check for enabled operations (/proc/sysrq-trigger - * should not) and is the invoked operation enabled? - */ - if (from == SYSRQ_FROM_KERNEL || sysrq_on_mask(op_p->enable_mask)) { + } else if (from == SYSRQ_FROM_KERNEL || sysrq_on_mask(op_p->enable_mask)) { + /* + * Should we check for enabled operations (/proc/sysrq-trigger + * should not) and is the invoked operation enabled? + */ pr_cont("%s\n", op_p->action_msg); console_loglevel = orig_log_level; op_p->handler(key);