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 C5486C43381 for ; Tue, 26 Mar 2019 18:57:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B42B20823 for ; Tue, 26 Mar 2019 18:57:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729489AbfCZS5f (ORCPT ); Tue, 26 Mar 2019 14:57:35 -0400 Received: from namei.org ([65.99.196.166]:58702 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726175AbfCZS5f (ORCPT ); Tue, 26 Mar 2019 14:57:35 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id x2QIv7YY007246; Tue, 26 Mar 2019 18:57:07 GMT Date: Wed, 27 Mar 2019 05:57:07 +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 Mon, 25 Mar 2019, Andy Lutomirski wrote: > A while back, I suggested an approach to actually make this stuff > mergeable: submit a patch series that adds lockdown mode, enables it > by command line option (and maybe sysctl) *only* and has either no > effect or only a token effect. Then we can add actual features to > lockdown mode one at a time and review them separately. This makes sense to me. > > And I'm going to complain loudly unless two things change about this > whole thing: > > 1. Lockdown mode becomes three states, not a boolean. The states are: > no lockdown, best-effort-to-protect-kernel-integrity, and > best-effort-to-protect-kernel-secrecy-and-integrity. And this BPF > mess illustrates why: most users will really strongly object to > turning off BPF when they actually just want to protect kernel > integrity. And as far as I know, things like Secure Boot policy will > mostly care about integrity, not secrecy, and tracing and such should > work on a normal locked-down kernel. So I think we need this knob. Another approach would be to make this entirely policy based: - Assign an ID to each lockdown point - Implement a policy mechanism where each ID is mapped to 0 or 1 - Allow this policy to be specified statically or dynamically So, 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? > 2. All the proponents of this series, and the documentation, needs to > document that it's best effort. There will always be security bugs, > and there will always be things we miss. Right. Maintaining this feature will be an ongoing effort, and if its not actively maintained, it will bitrot and become useless. -- James Morris