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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 805DDC64EBC for ; Tue, 2 Oct 2018 22:06:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 510CC2083F for ; Tue, 2 Oct 2018 22:06:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 510CC2083F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=namei.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-security-module-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727333AbeJCEwF (ORCPT ); Wed, 3 Oct 2018 00:52:05 -0400 Received: from namei.org ([65.99.196.166]:35266 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726809AbeJCEwF (ORCPT ); Wed, 3 Oct 2018 00:52:05 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id w92M6Ca3027182; Tue, 2 Oct 2018 22:06:12 GMT Date: Wed, 3 Oct 2018 08:06:12 +1000 (AEST) From: James Morris To: Kees Cook cc: John Johansen , Jordan Glover , Stephen Smalley , Paul Moore , Casey Schaufler , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter In-Reply-To: Message-ID: References: <20181002005505.6112-1-keescook@chromium.org> <20181002005505.6112-24-keescook@chromium.org> <785ef6a9-ae46-3533-0348-74bcf6f10928@tycho.nsa.gov> <809f1cfd-077b-ee58-51ba-b22daf46d12b@tycho.nsa.gov> 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, 2 Oct 2018, Kees Cook wrote: > On Tue, Oct 2, 2018 at 11:57 AM, John Johansen > wrote: > > Under the current scheme > > > > lsm.enabled=selinux > > > > could actually mean selinux,yama,loadpin,something_else are > > enabled. If we extend this behavior to when full stacking lands > > > > lsm.enabled=selinux,yama > > > > might mean selinux,yama,apparmor,loadpin,something_else > > > > and what that list is will vary from kernel to kernel, which I think > > is harder for the user than the lsm.enabled list being what is > > actually enabled at boot > > Ah, I think I missed this in your earlier emails. What you don't like > here is that "lsm.enable=" is additive. You want it to be explicit. > This is a path to madness. How about enable flags set ONLY per LSM: lsm.selinux.enable=x lsm.apparmor.enable=x With no lsm.enable, and removing selinux=x and apparmor=x. Yes this will break existing docs, but they can be updated for newer kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from kernel X onwards. Surely distro packages and bootloaders are able to cope with changes to kernel parameters? We can either take a one-time hit now, or build new usability debt, which will confuse people forever. -- James Morris