Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1175806imm; Thu, 13 Sep 2018 14:02:21 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda8M0SSmVlHB0BfyNzMfVcvno2h2g6kxClSndvh3XB5nzfJGhugH55IwepSkGssCEMDrk3p X-Received: by 2002:a63:6054:: with SMTP id u81-v6mr8766578pgb.433.1536872541081; Thu, 13 Sep 2018 14:02:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536872541; cv=none; d=google.com; s=arc-20160816; b=eC983ZC6SBNgf5EIiaGeC5PBHKXSrox5J6yTv+Ep9LDXpq7yEl9XM19RbetNT+JlEa +jfIuFHG7p+EXMTpJ7XXZoLsU3QhORQAw3RjV/tZ+DWuiSnle7N4FlDGFZTCi7ISWRzV IgdIfqz+DO4fgH9xPAL9IJL8DeAblOhDzJW3LXfctr5smFXozobN8bPN3YEPLdKTJqqh V/OaCITXWZvWesh2D0qltibMSSDImEUOml6NFsnuYOTbdC67YtvGZeEMmrj2CGuA7BDN yM7x7hnoGOMknI7G03DSOP/XdyJGn+Fljy5Gr1QVymg3KN1Wbhf4WyQHhGFVAaZLM2fM 8k5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=V93sSpgUrom8pF7o+5J1HdUbIMKj2Y26fPjs3mm8DsA=; b=tW7bbvDDsNuMG+hRkeUjys7zpfOhdz3LPMk5d8YWrNpXUwdV04bjOnKjSPal0S96Hv h2YWwReESj+nbO2ekGEfYF7T563/sXVba8FatOQHEdjZksr2gbcIiKFmHntZgdRn3Yga Ak77kQf7iYyQuIxMFlcXnQRo48PTDJPBE7Vn/m1csT+KVffvQMxKM8rXuAgtDGWwp6UZ D7WToqVTkf2BuHwrSemNgUp5/KK9VGh5TIJzmPvTEi4YZoLj9t9UERS6gmTJvLzpYJee GoM+Kd7U20/insX+Qw3R3lAVaUp7I/LD3UKaY4Ls0tEzSs0CKfhtzc1Ebcp4wUCQQ/sd D+tA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=n3ect4Dh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 32-v6si5132293plc.475.2018.09.13.14.02.05; Thu, 13 Sep 2018 14:02:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=n3ect4Dh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728054AbeINCNE (ORCPT + 99 others); Thu, 13 Sep 2018 22:13:04 -0400 Received: from mail-yb1-f195.google.com ([209.85.219.195]:36084 "EHLO mail-yb1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727774AbeINCNE (ORCPT ); Thu, 13 Sep 2018 22:13:04 -0400 Received: by mail-yb1-f195.google.com with SMTP id d34-v6so3898465yba.3 for ; Thu, 13 Sep 2018 14:01:52 -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=V93sSpgUrom8pF7o+5J1HdUbIMKj2Y26fPjs3mm8DsA=; b=n3ect4DhMwJYK3sqHzHBBG2MS+PPGYlA2oN/hwg9Lc16xALqtpB//mW+ZCYbUyhL8I PxxoVyJJ/c5S4Fk5O+3eMgZCGSiP//00y4vlMes93sFXmTZQtV9wMqhD2zFXxlcBT56Y pQF2KjJ7rM/94nVpNUSppfp90VXGRzijIR8rs= 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=V93sSpgUrom8pF7o+5J1HdUbIMKj2Y26fPjs3mm8DsA=; b=ayH+Mqf96OGsiQBy8IU3vXuOIaFBCBskcy/IruzHQCEENDB1bMNr/iAGKTXOWdq41m XipoD5JdS0csUup/1O3Sz78Zp1Sk3CAEtpZlB2zae83K1PwsbVGObFVQF8e5JBhlWU34 +qUDgdcRo/bBvOZViHihA64eFtpQuF56VKwl3nVW98nC8mDxAIMgp+ZmzxUTpUhAvCOC k+Lb9yUumITvnPK3t18rW2itG6sLSPc9J2yjkoeenSU/ZPnev4Fa67jqNb/gEST9FOjT vvD1SNM/MbBGQUH7uNIHW1uUBs6wDAL+TXpGlGC07eJDmjOtiUnPwnPNdhFFzt6PSp4I 1M3w== X-Gm-Message-State: APzg51CcJbN+/ivHXy/TSAJb7xPgbnb+wUlxChUbcEAqX7rDnbrkhj5g KmSLGUGpWzOa2MOo7F4tzQIJmZQmE/c= X-Received: by 2002:a25:1207:: with SMTP id 7-v6mr4311843ybs.470.1536872511245; Thu, 13 Sep 2018 14:01:51 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id i123-v6sm6396390ywe.14.2018.09.13.14.01.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 14:01:49 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id w184-v6so1469240ybe.11 for ; Thu, 13 Sep 2018 14:01:49 -0700 (PDT) X-Received: by 2002:a25:19c3:: with SMTP id 186-v6mr4386801ybz.410.1536872509237; Thu, 13 Sep 2018 14:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5f04:0:0:0:0:0 with HTTP; Thu, 13 Sep 2018 14:01:48 -0700 (PDT) In-Reply-To: References: <99cb1ae7-8881-eb9a-a8cb-a787abe454e1@schaufler-ca.com> From: Kees Cook Date: Thu, 13 Sep 2018 14:01:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock To: Paul Moore Cc: Casey Schaufler , linux-security-module , James Morris , LKML , SE Linux , John Johansen , Tetsuo Handa , Stephen Smalley , "linux-fsdevel@vger.kernel.org" , Alexey Dobriyan , "Schaufler, Casey" 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 Thu, Sep 13, 2018 at 12:12 PM, Paul Moore wrote: > None of the above deals with the user experience or support burden a > distro would have by forcing stacking on. If we make it an option the Just to make sure we're clear here: this series does not provide "extreme" stacking: SELinux, AppArmor, and SMACK remain boot-exclusive no matter what the CONFIGs. > distros can choose for themselves; picking a kernel build config is > not something new to distros, and I think Casey's text adequately > explains CONFIG_SECURITY_STACKING in terms that would be sufficient. I absolutely want stacking to be configurable, but I want to point out that there is no operational difference between CONFIG_SECURITY_STACKING=n and CONFIG_SECURITY_STACKING=y in the code here: - all the new accessor and allocation code is exercised in both cases - with stacking enabled: selinux, apparmor, and smack have an offset of 0 into blobs (and only one can be enabled at a time) - with stacking disabled: selinux, apparmor, and smack have an offset of 0 into blobs (and only one can be enabled at a time) The only behavioral difference is TOMOYO: 1- with stacking disabled and TOMOYO as the only major LSM, it will have a 0 offset into blobs (like above) 2- with stacking enabled and TOMOYO as the only major LSM, it will have a 0 offset into blobs (like above) 3- with stacking disabled and another major LSM is enabled, TOMOYO will be disabled (like always) 4- with stacking enabled and another major LSM is enabled, TOMOYO will have a non-0 offset into blobs and will run after selinux or smack or run before apparmor (based on link ordering defined by the Makefile). Note that cases 1, 2, and 3 are identical in behavior to before this series. Only case 4 is different, which is why I'm saying that instead of creating a redundant and needlessly complex config, or reinventing the "enable" wheel, we should simply drop the no-op CONFIG_SECURITY_STACKING config and provide TOMOYO with an "enable" parameter (and CONFIG). And it should be _separate_ from the "security=" line. This will be the SAME outcome for distros: if they want stacking, they choose the "enable TOMOYO by default" CONFIG. If they don't want stacking, they don't. > I currently have a neutral stance on stacking, making it mandatory > pushes me more towards a "no". This is why I'm trying to explain myself: the infrastructure proposed here is always exercised, no matter the CONFIG. From that sense it is "mandatory" no matter what the config is. There isn't a reality where you could "turn off stacking", because it's not stacking until you actually stack something, and that will be disabled by default as I've proposed it. Let me put this another way: if we simply leave off patch 10, we can take the other 9 patches (modulo feedback), and we only have to decide how to expose "stacking"; all the infrastructure work for supporting it is done. I'm arguing that "security=" is likely insufficient to describe what we want, and instead we should focus on individual LSM enablement via parameters ("tomoyo.enabled=1"). If _ordering_ becomes an issue, we could either use parameter order, or use "security=" again maybe, but for now, ordering is already defined by the Makefile (and security/security.c). "Stacking" only exists if you try to enable one of [selinux, apparmor, or smack] AND tomoyo. CONFIG_SECURITY_STACKING is redundant: if you want to disable stacking, you just disable tomoyo if you have another LSM (which we can already enforce in the Kconfig). If you want something more explicit than per-LSM config, then a simple "security.lsm_stack=1/0" with a CONFIG for the default would be fine. I'm trying to argue against what appears to be needless complexity around CONFIG_SECURITY_STACK as it was proposed, since it doesn't provide a meaningful operational change, since exclusivity of major LSMs is already handled. > As far as the cpp ifdef's, and other conditionals are concerned, I > remain unconvinced this is any worse than any other significant > feature that is a build time option. That's fine. That's just a code style issue. What I'm trying to show is that by lifting the allocation logic up out of the LSMs, we've actually simplified the logic. The "stacking" part will only become a distro-choice once they knowingly enable TOMOYO or build in SARA and/or Landlock in the future. -Kees -- Kees Cook Pixel Security