Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp229968yba; Wed, 17 Apr 2019 23:40:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqywOw0c45uXrao66533zifiyLzPEubnksCnppHfVlu6eIC3cPrf7AdQUdB5iKU6+wmGtvEc X-Received: by 2002:aa7:8252:: with SMTP id e18mr93301589pfn.105.1555569632022; Wed, 17 Apr 2019 23:40:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555569632; cv=none; d=google.com; s=arc-20160816; b=h1u9B8PpTGvEhu4uv8WI/uIFhbmjOH6bHeGj2gdrtrLskRTcQOv9q1GEHax4DCS6u1 GKbmUEBWcQRLaCURqfypsX4PildvG4eRFNB5JLHxsihsvKnb8NL1p+KuxbWl856ffL95 dM7+azj85x8+3g/ieSsXpdWhXWwdSSkAOQPoDhLGFplMTbFlAbqqqwBIcDc7yEZwx0qo F02k++/jLaYxg/RIx6xDQrbUIexzBMqEqEtyI0Htx8Y8mdaLgWnJ3xOvmAJPJT8xxF3t tzjKjFPTacTXDD1QQffPzQP9TdvQlGFwdfTVUJSGOMIMtwYIHZ0NlPJqWLMmOt7J4x8k A7wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=nY+EP2R9METKYDuku3g6nVrECtlVH8EVx2p8MKZ118k=; b=nvyLcNpKrxhLYA4RgOietH9B+3OME9rgmxiA/jsgUgasgf3kKZpr1A9StzS+plqCup epZZ9GLhAKUPrUeHOo3nQdp376FybPYLdkjmTVt6W+b3ly+jU0/wf9P54t9bQWNqGHx9 6fhNJcZzoALnZ2R5Yb6cpzR6Pfg+ds9wrR9pX126ESg1FwJ+h9IRIkhwcbygesfV5/M5 ikCDUpb9luDl0wo4yfkLqvnY2nuO+/KKBiYLsbEfvprO9ynBx79G1fghnRfP08krU1rI yAbyknJ2RdO9VFxDHTa64rqdSWjqW7Qj1Of1JtKhCVeekJGYJHF7u9BvpXpXty+erA2t V39w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=qPeJj8KN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cs8si1312433plb.393.2019.04.17.23.40.17; Wed, 17 Apr 2019 23:40:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=qPeJj8KN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388083AbfDRGjB (ORCPT + 99 others); Thu, 18 Apr 2019 02:39:01 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:37857 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387990AbfDRGjA (ORCPT ); Thu, 18 Apr 2019 02:39:00 -0400 Received: by mail-pg1-f194.google.com with SMTP id e6so721407pgc.4 for ; Wed, 17 Apr 2019 23:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=nY+EP2R9METKYDuku3g6nVrECtlVH8EVx2p8MKZ118k=; b=qPeJj8KNRZcPDLVMnDM575b8I8uxbwGFOuzY1O3nklzeCIIQBISrbzJ1N2wdOOVj+/ I2IJoL0wlUjVDUzGjZyXUMsftii3pT3o2enK8JGO4UOPTEQsNXyaxFXIXnFoUE+/hCXC czjEDUc/+Pf6wCKACtzH7LS3kSMb4SIBPrxSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=nY+EP2R9METKYDuku3g6nVrECtlVH8EVx2p8MKZ118k=; b=dQwnuS/Ohbf9fMiDfti9JMEGSDgQwR8QBXM4Hw6mF4rQE7bRI9kgBsE1M/c2J/Xzgl w+U2j69h2Rg+mkRJxnbj/b0DZ0TtKux01/TGlZt+gTHJ0l86OIbrmROa8cobkMub9gq3 99DR93/8iq0dcTnMJlfc/OGZvK8mODVGElgYN9/zZ9Ncb237zS/ghnwYzAeBZ9hT2qdA 1IqsVyZ9Y3jRWzqOau8nzf6CiPVpp1lvoZibZte8Eg7pYsjreTJQIW5rygbUyoZ72RJX lx3byi0d4fj6oWJf8CBqQTmZ6Imo2zKfgrN9RTTVurjnMfESpD3gOn+/No3hSluDOjNC rV5g== X-Gm-Message-State: APjAAAVEDc1TbQcp9NM8vn65ZfhRTrmWKumqM4y7UhRlsBMO9aN00s5K DTjoSPpcJqwIssnHzJLaFnRrJw== X-Received: by 2002:a63:3857:: with SMTP id h23mr85072995pgn.305.1555569540173; Wed, 17 Apr 2019 23:39:00 -0700 (PDT) Received: from localhost (124-171-99-108.dyn.iinet.net.au. [124.171.99.108]) by smtp.gmail.com with ESMTPSA id o81sm1603642pfa.156.2019.04.17.23.38.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 23:38:59 -0700 (PDT) From: Daniel Axtens To: Andrew Donnellan , Matthew Garrett , jmorris@namei.org Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, dhowells@redhat.com, linux-api@vger.kernel.org, luto@kernel.org, linuxppc-dev , Michael Ellerman , cmr Subject: Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image In-Reply-To: <059c523e-926c-24ee-0935-198031712145@au1.ibm.com> References: <20190404003249.14356-1-matthewgarrett@google.com> <20190404003249.14356-2-matthewgarrett@google.com> <059c523e-926c-24ee-0935-198031712145@au1.ibm.com> Date: Thu, 18 Apr 2019 16:38:54 +1000 Message-ID: <87zhonyg01.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, >> + If CONFIG_LOCK_DOWN_KERNEL is enabled, the kernel can be >> + moved to a more locked down state at runtime by writing to >> + this attribute. Valid values are: >> + >> + integrity: >> + The kernel will disable functionality that allows >> + userland to modify the running kernel image, other >> + than through the loading or execution of appropriately >> + signed objects. >> + >> + confidentiality: >> + The kernel will disable all functionality disabled by >> + the integrity mode, but additionally will disable >> + features that potentially permit userland to obtain >> + confidential information stored within the kernel. > > [+ linuxppc, mpe, dja, cmr] > > I'm thinking about whether we should lock down the powerpc xmon debug > monitor - intuitively, I think the answer is yes if for no other reason > than Least Astonishment, when lockdown is enabled you probably don't > expect xmon to keep letting you access kernel memory. > > Semantically though, xmon is not a userspace process - it's in kernel > and reads debug commands/outputs debug data directly from/to the > console. Is that a threat vector that this series cares about? I guess there are 2 ways you could think about lockdown: - It adds a security boundary between the kernel and UID 0, so that userland cannot compromise the integrity/confidentiality of the locked down kernel. - It is a bundle of related security boundaries so that the integrity/confidentiality of a running, locked down kernel cannot be compromised, even by a privileged, physically present user. You're right that techincally xmon is in the kernel and on the console rather than in userland, so it doesn't fall within the first concept of lockdown. But I think usecases for lockdown tend to expect something more like the second concept. IOW, lockdown is a trapdoor - once you've locked down a kernel, you can't get out of lockdown (except by rebooting). xmon would allow you to get out of the trapdoor, so I think it should be restricted by lockdown. Regards, Daniel > > > -- > Andrew Donnellan OzLabs, ADL Canberra > andrew.donnellan@au1.ibm.com IBM Australia Limited