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,URIBL_BLOCKED autolearn=ham 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 3C410C43381 for ; Thu, 28 Mar 2019 03:16:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 16CC9206C0 for ; Thu, 28 Mar 2019 03:16:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728154AbfC1DQP (ORCPT ); Wed, 27 Mar 2019 23:16:15 -0400 Received: from namei.org ([65.99.196.166]:59014 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726176AbfC1DQP (ORCPT ); Wed, 27 Mar 2019 23:16:15 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id x2S3Fkde027824; Thu, 28 Mar 2019 03:15:46 GMT Date: Thu, 28 Mar 2019 14:15:46 +1100 (AEDT) From: James Morris To: Andy Lutomirski cc: Stephen Hemminger , Linux API , Matthew Garrett , LSM List , LKML , David Howells , Alexei Starovoitov , Network Development , Chun-Yi Lee , Daniel Borkmann , Kees Cook , Will Drewry Subject: Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down In-Reply-To: Message-ID: References: <20190325220954.29054-1-matthewgarrett@google.com> <20190325220954.29054-24-matthewgarrett@google.com> <20190325164221.5d8687bd@shemminger-XPS-13-9360> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Tue, 26 Mar 2019, Andy Lutomirski wrote: > > > > kernel_is_locked_down("ioperm") > > > > becomes > > > > kernel_is_locked_down(LOCKDOWN_IOPERM) > > > > and this function checks e.g. > > > > if (lockdown_polcy[id]) { > > fail or warn; > > } > > > > Thoughts? > > I'm concerned that this gives too much useless flexibility to > administrators and user code in general. If you can break kernel > integrity, you can break kernel integrity -- it shouldn't really > matter *how* you break it. OTOH, this seems like a combination of mechanism and policy. The 3 modes are a help here, but I wonder if they may be too coarse grained still, e.g. if someone wants to allow a specific mechanism according to their own threat model and mitigations. Secure boot gives you some assurance of the static state of the system at boot time, and lockdown is certainly useful (with or without secure boot), but it's not a complete solution to runtime kernel integrity protection by any stretch of the imagination. I'm concerned about it being perceived as such. I'm not sure how to think about it architecturally and how it fits as such in the mainline kernel. -- James Morris