Received: by 10.213.65.68 with SMTP id h4csp1409007imn; Wed, 4 Apr 2018 19:18:33 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/GSRmhhrjNRwfOvhnRu09rM3WaWObzgZDZHw8WFjjs6XJBi+HuICLvKw0jxWGQp++HJujx X-Received: by 10.98.89.23 with SMTP id n23mr15639359pfb.211.1522894713547; Wed, 04 Apr 2018 19:18:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522894713; cv=none; d=google.com; s=arc-20160816; b=A24FKBCZKHgsTz0BBxAYFTF4FyFqI/mLpIEiVkxA0L70WMnpECA/8OXTZsVhnFbRyo 7fwbY8VUCjrCxTUjaiNFLlllKAarpnKKJ3ItcBhFgpG66uVGtslETXktcguLMegPKwZE Ad8f+p4ChhnYiUeHyNrkepSXAE7UYifAPa8diQAVYlzPXW+m/Cztl17H2559Il22CB+B OcR35Q7eH+Rdf75S/e6mesJlA9NaikWTa5cFbeeodKKtfu9xpq/EYN5oHJDFuFn698vd r0ynW+iHJYSxIbLeaZfaHt75L8E1RUpAZkpQwSKedNLIqWS95OZ7jLJRJLiMn3t3vlcB l5LA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=VcPCiK3eZBeudfLj92ofv4jdAtDfjmT9uUo7ZqbJUGQ=; b=esQ2jC4qMM7lV7jYOaR0dLNGfgl4joE5RMl9yYNBynilVPsOn2OXYtd8Ws4+MvasDX fJqah6FsOD2pEAaBA9aSj9UASGMbJagPfnGSPQGHYgOdPSHFxj89m6mAkbcSEFVHFu7d nJzbfnZGBntE/stf1DxXwpdrtirhdtlgFk6Ck2cLezgGRlB3m7vRcGthTQ98bOuYrAMj d83E/WylXR+Ce2KFbwYsoWq752vrElBsw2gjus3Ii8bRgnBRa51PKPCPgbZXthMQ9P4W U9ai4rAkb+I/FQChWIBKKaY28zNqgh6tR8ejZ2FPt3qosj8sl4Xp3E38ppQQFjFTemcQ U1sg== ARC-Authentication-Results: i=1; mx.google.com; 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 x185si4567728pgb.649.2018.04.04.19.18.17; Wed, 04 Apr 2018 19:18:33 -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; 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 S1752790AbeDECRI (ORCPT + 99 others); Wed, 4 Apr 2018 22:17:08 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:40318 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752674AbeDECRH (ORCPT ); Wed, 4 Apr 2018 22:17:07 -0400 Received: from linux-l9pv.suse (124-11-22-254.static.tfn.net.tw [124.11.22.254]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Thu, 05 Apr 2018 04:16:58 +0200 Date: Thu, 5 Apr 2018 10:16:50 +0800 From: joeyli To: David Howells Cc: Andy Lutomirski , Greg Kroah-Hartman , "Theodore Y. Ts'o" , Matthew Garrett , Linus Torvalds , Ard Biesheuvel , James Morris , Alan Cox , Linux Kernel Mailing List , Justin Forbes , linux-man , LSM List , Linux API , Kees Cook , linux-efi Subject: Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot) Message-ID: <20180405021650.GC7362@linux-l9pv.suse> References: <1119.1522858644@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1119.1522858644@warthog.procyon.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote: > Andy Lutomirski wrote: > > > Since this thread has devolved horribly, I'm going to propose a solution. > > > > 1. Split the "lockdown" state into three levels: (please don't > > bikeshed about the names right now.) > > > > LOCKDOWN_NONE: normal behavior > > > > LOCKDOWN_PROTECT_INTEGREITY: kernel tries to keep root from writing to > > kernel memory > > > > LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY: kernel tries to keep root from > > reading or writing kernel memory. > > In theory, it's good idea, but in practice it's not as easy to implement as I > think you think. > > Let me list here the things that currently get restricted by lockdown: > [...snip] > (5) Kexec. > About IMA with kernel module signing and kexec(not on x86_64 yet)... Because IMA can be used to verify the integrity of kernel module or even the image for kexec. I think that the IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY must be enabled at runtime when kernel is locked-down. Because the root can enroll master key to keyring then IMA trusts the ima key derived from master key. It causes that the arbitrary signed module can be loaded when the root compromised. Thanks Joey Lee