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=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 AE965C00449 for ; Mon, 1 Oct 2018 22:27:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 66C05206B2 for ; Mon, 1 Oct 2018 22:27:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="kY92xw1k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 66C05206B2 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-security-module-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726427AbeJBFHp (ORCPT ); Tue, 2 Oct 2018 01:07:45 -0400 Received: from mail-yb1-f196.google.com ([209.85.219.196]:37020 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726291AbeJBFHo (ORCPT ); Tue, 2 Oct 2018 01:07:44 -0400 Received: by mail-yb1-f196.google.com with SMTP id h1-v6so4208824ybm.4 for ; Mon, 01 Oct 2018 15:27:44 -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=qiWHG4Dgx9fa+Wn3UGykfw3svCqVxxYaSRv8xlRJIC0=; b=kY92xw1khe3By6mw0Xem4VGnQPNeu2dBNvwIvCFWa2ivWBXfRQBI8i0SBm4t9jprju H6BUKDPtv8yqZ9DQ2KGyIThPW4E/QwSWrL+boVdxYXDskW6AHkQDUvSo67LnD+oowNtF 3tstWJme0Hkz9uGAYMGGDuz8gPpSeEpSrQwKQ= 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=qiWHG4Dgx9fa+Wn3UGykfw3svCqVxxYaSRv8xlRJIC0=; b=QYak2gg6NU5U8p//vTc3/e9KYD1+xo2KaikCwB21jsaF9iUVn/P+OGg9i/k3c8JqG3 uWVofqnSd+UzYGv3AOwKkMWJbAm3V9TByH8bC2ufGh4Bu19ZHrmi/pq5Qh4rwmn8MsI2 ktybGWkMLFNI2UvkBHLHO+5xvaDDsC+oUGNMyXUKw89A8RakZTCKVs04ppbEnnjDxDIB fOVNNhNBdvVUvnFV9oMvh83wRvJfMDgzqOC+F1vsYraewnQabKqFOOPTpfTiWksqkZMx CY0xzvrsTaXOSr9r288lzNKkdLr1DIhrdoBnCHRNJj47X65mKhZG6L/oCWlbHY5tBZoE 43/g== X-Gm-Message-State: ABuFfojl/XvempeSXeNFWfN0HHzus2ItBuJO566rNcFMHmbb/Gtsdd25 L424eZ9czA27W/Qwf2XvJ4i3jzKIGT8= X-Google-Smtp-Source: ACcGV63hi2UGZGVHb1WNynnOetnUpxXW4CBEB3hzy/3+rYzajn7Q6kNwE1EavnyQIPm0B2J9a8rWxQ== X-Received: by 2002:a25:39c2:: with SMTP id g185-v6mr7061000yba.74.1538432863391; Mon, 01 Oct 2018 15:27:43 -0700 (PDT) Received: from mail-yw1-f53.google.com (mail-yw1-f53.google.com. [209.85.161.53]) by smtp.gmail.com with ESMTPSA id e82-v6sm12461972ywa.60.2018.10.01.15.27.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 15:27:42 -0700 (PDT) Received: by mail-yw1-f53.google.com with SMTP id l79-v6so2107073ywc.7 for ; Mon, 01 Oct 2018 15:27:41 -0700 (PDT) X-Received: by 2002:a81:1194:: with SMTP id 142-v6mr7226725ywr.168.1538432861376; Mon, 01 Oct 2018 15:27:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d116:0:0:0:0:0 with HTTP; Mon, 1 Oct 2018 15:27:40 -0700 (PDT) In-Reply-To: <68e4e323-3216-7e77-2807-c3207126ae68@canonical.com> References: <20180925001832.18322-1-keescook@chromium.org> <20180925001832.18322-19-keescook@chromium.org> <68e4e323-3216-7e77-2807-c3207126ae68@canonical.com> From: Kees Cook Date: Mon, 1 Oct 2018 15:27:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= To: John Johansen , Paul Moore Cc: James Morris , Casey Schaufler , Tetsuo Handa , Stephen Smalley , "Schaufler, Casey" , LSM , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Mon, Oct 1, 2018 at 2:46 PM, John Johansen wrote: > On 09/24/2018 05:18 PM, Kees Cook wrote: >> This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters >> which each can contain a comma-separated list of LSMs to enable or >> disable, respectively. The string "all" matches all LSMs. >> >> This has very similar functionality to the existing per-LSM enable >> handling ("apparmor.enabled=...", etc), but provides a centralized >> place to perform the changes. These parameters take precedent over any >> LSM-specific boot parameters. >> >> Disabling an LSM means it will not be considered when performing >> initializations. Enabling an LSM means either undoing a previous >> LSM-specific boot parameter disabling or a undoing a default-disabled >> CONFIG setting. >> >> For example: "lsm.disable=apparmor apparmor.enabled=1" will result in >> AppArmor being disabled. "selinux.enabled=0 lsm.enable=selinux" will >> result in SELinux being enabled. >> >> Signed-off-by: Kees Cook > > I don't like this. It brings about conflicting kernel params that are > bound to confuse users. Its pretty easy for a user to understand that > when they specify a parameter manually at boot, that it overrides the > build time default. But conflicting kernel parameters are a lot harder > to deal with. > > I prefer a plain enabled= list being an override of the default build > time value. Where conflicts with LSM-specific configs always result in > the LSM being disabled with a complaint about the conflict. > > Though I have yet to be convinced its worth the cost, I do recognize > it is sometimes convenient to disable a single LSM, instead of typing > in a whole list of what to enable. If we have to have conflicting > kernel parameters I would prefer that the conflict throw up a warning > and leaving the LSM with the conflicting config disabled. Alright, let's drill down a bit more. I thought I had all the requirements sorted out here. :) AppArmor and SELinux are "special" here in that they have both: - CONFIG for enable-ness - boot param for enable-ness Now, the way this worked in the past was that combined with CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a way to get the LSM enabled, skipped, etc. But it was highly CONFIG dependent. SELinux does: #ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE; static int __init selinux_enabled_setup(char *str) { unsigned long enabled; if (!kstrtoul(str, 0, &enabled)) selinux_enabled = enabled ? 1 : 0; return 1; } __setup("selinux=", selinux_enabled_setup); #else int selinux_enabled = 1; #endif ... if (!security_module_enable("selinux")) { selinux_enabled = 0; return 0; } if (!selinux_enabled) { pr_info("SELinux: Disabled at boot.\n"); return 0; } AppArmor does: /* Boot time disable flag */ static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE; module_param_named(enabled, apparmor_enabled, bool, S_IRUGO); static int __init apparmor_enabled_setup(char *str) { unsigned long enabled; int error = kstrtoul(str, 0, &enabled); if (!error) apparmor_enabled = enabled ? 1 : 0; return 1; } __setup("apparmor=", apparmor_enabled_setup); ... if (!apparmor_enabled || !security_module_enable("apparmor")) { aa_info_message("AppArmor disabled by boot time parameter"); apparmor_enabled = false; return 0; } Smack and TOMOYO each do: if (!security_module_enable("smack")) return 0; if (!security_module_enable("tomoyo")) return 0; Capability, Integrity, Yama, and LoadPin always run init. (This series fixes LoadPin to separate enable vs enforce, so we can ignore its "enable" setting, which isn't an "am I active?" boolean -- its init was always run.) With the enable logic is lifted out of the LSMs, we want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I had originally suggested CONFIG_LSM_DISABLE, since the normal state is enabled.) But given your feedback, I made this "implicit disable" and added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all" gets the same results.) I think, then, the first question (mainly for you and Paul) is: Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only CONFIG_LSM_ENABLE? The answer will affect the next question: what should be done with the boot parameters? AppArmor has two ways to change enablement: apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1. Should those be removed in favor of "lsm.enable=..."? (And if they're not removed, how do people imagine they should interact?) Thanks! -Kees -- Kees Cook Pixel Security