Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7671470yba; Thu, 2 May 2019 14:08:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqx/Swymyw8SAFJCgT/YQFjyhNpQnNT+bsNFVYPWHkV6e61F28cSpwNbrGZ2FXRByrg7rZnc X-Received: by 2002:a63:e042:: with SMTP id n2mr6141476pgj.45.1556831314464; Thu, 02 May 2019 14:08:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556831314; cv=none; d=google.com; s=arc-20160816; b=0dfZc8w9R5LPNmk/jdpfu+bulbzOMoXRLcmDONumQLFV/aKdxLpgKX7tJkyazWl6wR YTuzSkP1KHa21uUpagyV3LC8qURSIWCi9hVHDmoAi0PsEmJvlrgwF0mWHA6i7EwvlMpM aIbpiA138rLuZj5YyLVjqyiWJ3RJ0EUhW3u2l8yCiNyWRWqMf97J0MOQtDRwp7LdhT4Z 7U2ZQaFezEzvCNVH3kX1rut3Q3rJ0hGj9XDpHAT1JbiqAQaFgh2JDxezTCy/QmPcY08E tjETfkuEYOF6lfTRJnnoUjd7+uk6cPqq51LAKAQFfwQaoNo4ihZ9ESCaSJAnq550crdv anwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=OuS47DO+b/crvJG/LoC7gXZH1hsM5wuOQW3jRrTpGIs=; b=0PfzfjbDx3cND0zlgByUo2unUFBHXxl6GP8BSwks2/SrCVPxkc3fVJN0Mr1rTMuMjG EGma/ueu2YWQwkaOe/V6pp1NzCacZt99lnU5XozstjrRNB73i+ZOGkc/lkagL8lCwgQm SWmLVNcBR7h5goxjVf1U1cR8YndwJpn9hF6T2VlbTmzLwPPqswkdOorO5uwlmQOdhHex DU+OZOqd8WK0LlYF3XDeLcBa6ULxFPUfNlpr19xlYHnepur3bqtyJtFwXGNBrKAwcyEp p7MQGUl8NEJ9pdTR+vfqwVGXF5YcgM7kivshrGJO/xBZnD/9p+PbtUJw+gYekgH4j2Lf Xo7w== 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 d2si133970pgh.499.2019.05.02.14.08.18; Thu, 02 May 2019 14:08:34 -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 S1726366AbfEBVHV (ORCPT + 99 others); Thu, 2 May 2019 17:07:21 -0400 Received: from namei.org ([65.99.196.166]:37082 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725962AbfEBVHV (ORCPT ); Thu, 2 May 2019 17:07:21 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id x42L7F4G000848; Thu, 2 May 2019 21:07:15 GMT Date: Fri, 3 May 2019 07:07:15 +1000 (AEST) From: James Morris To: Matthew Garrett cc: LSM List , Linux Kernel Mailing List , David Howells , Linux API , Andy Lutomirski Subject: Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image In-Reply-To: Message-ID: References: <20190404003249.14356-1-matthewgarrett@google.com> <20190404003249.14356-2-matthewgarrett@google.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Apr 2019, Matthew Garrett wrote: > Hi James, > > What's the best way forward with this? I'm still not entirely clear on > how it can be implemented purely as an LSM, but if you have ideas on > what sort of implementation you'd prefer I'm happy to work on that. It can't be implemented purely as an LSM. The concerns I have are: o Mixing of mechanism and policy (they are hardcoded together) o Too-coarse policy (all or nothing, which will lead many to choose nothing) o Lack of integration with LSM o Completeness o Maintenance (including adding new lockdowns without breaking existing userspace) One possible direction is to (as previously mentioned) assign IDs to each callsite and be able to check this ID against a simple policy array (allow/deny). The default policy choices could be reduced to 'all' or 'none' during kconfig, and allow a custom policy to be loaded later if desired. Within the policy check hook, we could add a new LSM hook, which would allow an LSM to restrictively override the lockdown policy with its own (so e.g. SELinux could utilize the context of the current process to determine if a lockdown feature should be enforced). This doesn't really address the completeness / maintenance issue (i.e. "do we have everything covered and how do we ensure this on an ongoing basis?", and "what will this new lockdown feature break?"), although it should make it easier to add new lockdown callsites as they don't have to be enabled by the user. Thoughts? -- James Morris