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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 7758FC64EB8 for ; Wed, 3 Oct 2018 20:36:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 32D9C213A2 for ; Wed, 3 Oct 2018 20:36:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="MOg30Bv7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32D9C213A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727245AbeJDD0N (ORCPT ); Wed, 3 Oct 2018 23:26:13 -0400 Received: from mail-yw1-f68.google.com ([209.85.161.68]:32808 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727092AbeJDD0M (ORCPT ); Wed, 3 Oct 2018 23:26:12 -0400 Received: by mail-yw1-f68.google.com with SMTP id m127-v6so2881053ywb.0 for ; Wed, 03 Oct 2018 13:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wpFr+Hx2NbVy/3EKUYPoL01zFPb1EwjCpAZhF1GQotc=; b=MOg30Bv7tHPEVqfq4sdyfblhl/GzBPRza0X1/0VWWk5u1jUcBPuObp9VPmc0024Jx2 QQgmIFYAlJp4wO4HZV8dPKR+qTVyAK1gpTZg1ascP4mJtCxCBW9bcoWDqIxfOvE8Y/3i YU4A3i/+iWIXQMce0nD1g4RP2hC+AbCnF/k2U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wpFr+Hx2NbVy/3EKUYPoL01zFPb1EwjCpAZhF1GQotc=; b=cMb9/qx6tMql0Ey+/E5ffCqyiqORuGDPk8dnyzktmJP9GULvhWbvUR7ZHYW4Pei4uQ yJ5xwZnrIa/oZvVu/TOp8nCjP0giqYyVA7ZlzM4+KJsZ+1Wdfi1Uoy6fLXpuM5td+7Xo VQioYbl4fQ+IrouFVkYGjsL9Y6RMji4/C36CZfdt0BhN6Zc2htugW1DJyLH4eyfcHFY7 4sBkwnSf87J1/I1/p8a7VzyRv6wnrksINjkKWnLhq4ALIa5ugU0iusIMUU3R3QE5AaKi kIOreYLcrEVx9RkzlXrvYEV8Auq8WuxW2WHUpcd06vhM5XZ/bcdmUu7tZM7Yxl6QbTQT jmzQ== X-Gm-Message-State: ABuFfohGmhyzZ8cdkMYJEyPW4TIRubT3U0Qm5iYI06ZIeiPJRdIIHgQg 6y6StDzXA/BKul62/+E3QA11WNj/THs= X-Google-Smtp-Source: ACcGV60gdpX56X9UpeJQWFt+9nHznX0GNS20u6Lc0if5OL8W6UrH0TEZ8pnP6OxXrRJp5DboKnwj1A== X-Received: by 2002:a81:4686:: with SMTP id t128-v6mr1944036ywa.52.1538598973581; Wed, 03 Oct 2018 13:36:13 -0700 (PDT) Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com. [209.85.219.181]) by smtp.gmail.com with ESMTPSA id s200-v6sm943276ywg.61.2018.10.03.13.36.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 13:36:11 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id u88-v6so2987778ybi.0 for ; Wed, 03 Oct 2018 13:36:10 -0700 (PDT) X-Received: by 2002:a25:2395:: with SMTP id j143-v6mr1934723ybj.137.1538598970262; Wed, 03 Oct 2018 13:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d116:0:0:0:0:0 with HTTP; Wed, 3 Oct 2018 13:36:09 -0700 (PDT) In-Reply-To: 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> <5955f5ce-b803-4f58-8b07-54c291e33da5@canonical.com> From: Kees Cook Date: Wed, 3 Oct 2018 13:36:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter To: James Morris 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook wrote: > On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote: >> On Wed, 3 Oct 2018, Kees Cook wrote: >> >>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote: >>> > On Tue, 2 Oct 2018, John Johansen wrote: >>> >> To me a list like >>> >> lsm.enable=X,Y,Z >>> > >>> > What about even simpler: >>> > >>> > lsm=selinux,!apparmor,yama >>> >>> We're going to have lsm.order=, so I'd like to keep it with a dot >>> separator (this makes it more like module parameters, too). You want >>> to mix enable/disable in the same string? That implies you'd want >>> implicit enabling (i.e. it complements the builtin enabling), which is >>> opposite from what John wanted. >>> >> >> Why can't this be the order as well? > > That was covered extensively in the earlier threads. It boils down to > making sure we do not create a pattern of leaving LSMs disabled by > default when they are added to the kernel. The v1 series used > security= like this: > > + security= [SECURITY] An ordered comma-separated list of > + security modules to attempt to enable at boot. If > + this boot parameter is not specified, only the > + security modules asking for initialization will be > + enabled (see CONFIG_DEFAULT_SECURITY). Duplicate > + or invalid security modules will be ignored. The > + capability module is always loaded first, without > + regard to this parameter. > > This meant booting "security=apparmor" would disable all the other > LSMs, which wasn't friendly at all. So "security=" was left alone (to > leave it to only select the "major" LSM: all major LSMs not matching > "security=" would be disabled). So I proposed "lsm.order=" to specify > the order things were going to be initialized in, but to avoid kernels > booting with newly added LSMs forced-off due to not being listed in > "lsm.order=", it had to have implicit fall-back for unlisted LSMs. > (i.e. anything missing from lsm.order would then follow their order in > CONFIG_LSM_ORDER, and anything missing there would fall back to > link-time ordering.) However, then the objection was raised that this > didn't provide a way to explicitly disable an LSM. So I proposed > lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over > CONFIG_LSM_DISABLE. I still think we should have all built LSMs enabled by default, with CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER declares their order, "lsm.order=" works as mentioned, and "lsm.enable/disable=" make changes to what's enabled. (This would be most like the v3 series, swapping CONFIG_LSM_ENABLE for CONFIG_LSM_DISABLE.) It gives us centralized ordering and centralized disabling. Distros wanting specific LSMs are already building them, so _also_ adding them to CONFIG_LSM_ENABLE seems redundant to me. Distros wanting all the LSMs just want to declare the order of initialization, and maybe add some to CONFIG_LSM_DISABLE some day, so they use CONFIG_LSM_ORDER. I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY in, since it's just a way to disable all the other majors. I don't like this because it will force LSMs to be disabled that don't need to be once blob-sharing lands. The whole point of this series is to get us away from fixed ordering and thinking about "major" vs "minor" and towards "exclusive" or not, where we can continue to slowly chip away at exclusivity without breaking anything. -Kees -- Kees Cook Pixel Security