From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CADCC04AAA for ; Thu, 2 May 2019 23:19:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 389092064A for ; Thu, 2 May 2019 23:19:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726381AbfEBXT4 (ORCPT ); Thu, 2 May 2019 19:19:56 -0400 Received: from namei.org ([65.99.196.166]:37112 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726022AbfEBXT4 (ORCPT ); Thu, 2 May 2019 19:19:56 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id x42NJnjw008283; Thu, 2 May 2019 23:19:49 GMT Date: Fri, 3 May 2019 09:19:49 +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 Thu, 2 May 2019, Matthew Garrett wrote: > On Thu, May 2, 2019 at 2:07 PM James Morris wrote: > > 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. > > Ok. My primary concern around this is that it's very difficult to use > correctly in anything other than the "all" or "none" modes. If a new > kernel feature is added with integrated lockdown support, if an admin > is simply setting the flags of things they wish to block then this > will be left enabled - and may violate the admin's expectations around > integrity. On the other hand, if an admin is simply setting the flags > of things they wish to permit, then adding lockdown support to an > existing kernel feature may result in that feature suddenly being > disabled, which may also violate the admin's expectations around the > flags providing a stable set of behaviour. Understood. Most uses will likely be either a distro or an embedded system, who I'm assuming would provide a useful policy by default, and perhaps a high-level abstraction for modification. > Given that, would you prefer such a policy expression to look like? Perhaps a write-once policy, injected from userspace during early boot? The policy could be simply a list of: lockdown_feature true|false > > > 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 > > Ok, that makes sense. If we take this approach, does there need to be > a separate policy mechanism at all? Users who want fine-grained > control would be able to set the behaviour to "None" and then use > their choice of LSM to express more fine-grained control. Right, and there could be a stackable LSM which just does fine-grained policy (per above). > > > 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. > > I can start on this. Cool! -- James Morris