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.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FREEMAIL_REPLYTO_END_DIGIT,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 C3EE3C28CF8 for ; Fri, 12 Oct 2018 00:11:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7C6A220835 for ; Fri, 12 Oct 2018 00:11:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=protonmail.ch header.i=@protonmail.ch header.b="kX2/+2VT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C6A220835 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=protonmail.ch 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 S1727370AbeJLHlU (ORCPT ); Fri, 12 Oct 2018 03:41:20 -0400 Received: from mail-40135.protonmail.ch ([185.70.40.135]:21745 "EHLO mail-40135.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726108AbeJLHlU (ORCPT ); Fri, 12 Oct 2018 03:41:20 -0400 Date: Fri, 12 Oct 2018 00:11:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=default; t=1539303098; bh=R9YJ0WBGDm6ageo88/BRQUUmTFlQCv4Z3xaPCSe6Lso=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=kX2/+2VTZHKwtASOPBBGxHV8WyoMugii3a3s9nfUOlLCHuIUfpfyeCSXnuNQ8LlfH /wAEW/rBI4W3NTxvo8+LymLFEBFfDwW3FAeEdyiFHgTge/jwAmVHeXwdhVOIvNJJaH XE2Qdmx9M7yHjhg19CKGYpVmCVzY5fVuE5yvorNA= To: John Johansen From: Jordan Glover Cc: Kees Cook , James Morris , Casey Schaufler , Stephen Smalley , Paul Moore , Tetsuo Handa , Mimi Zohar , Randy Dunlap , LSM , "open list:DOCUMENTATION" , linux-arch , LKML Reply-To: Jordan Glover Subject: Re: [PATCH security-next v5 00/30] LSM: Explict ordering Message-ID: <32stV62RmME8Dj5jKB8Z03zPe_Et72kMo71D8SpgSOHUo6SaROc8DomMWdk5jDGpyqVd8T63NIIK2NdDw95clpF8Uj47Wca2FBFItXDRh7E=@protonmail.ch> In-Reply-To: References: <20181011001846.30964-1-keescook@chromium.org> Feedback-ID: QEdvdaLhFJaqnofhWA-dldGwsuoeDdDw7vz0UPs8r8sanA3bIt8zJdf4aDqYKSy4gJuZ0WvFYJtvq21y6ge_uQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday, October 12, 2018 1:48 AM, John Johansen wrote: > On 10/11/2018 04:09 PM, Kees Cook wrote: > > > On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover > > Golden_Miller83@protonmail.ch wrote: > > > > > On Thursday, October 11, 2018 7:57 PM, Kees Cook keescook@chromium.or= g wrote: > > > > > > > To switch to SELinux at boot time with > > > > "CONFIG_LSM=3Dyama,loadpin,integrity,apparmor", the old way con= tinues to > > > > work: > > > > > > > > selinux=3D1 security=3Dselinux > > > > > > > > This will work still, since it will enable selinux (selinux=3D1= ) and > > > > disable all other major LSMs (security=3Dselinux). > > > > > > > > The new way to enable selinux would be using > > > > "lsm=3Dyama,loadpin,integrity,selinux". > > > > > > > > > > It seems to me that legacy way is more user friendly than the new one= . > > > AppArmor and SElinux are households names but the rest may be enigmat= ic > > > for most users and the need for explicit passing them all may be > > > troublesome. Especially when the new ones like sara,landlock or cows = :) > > > will be incoming. Moreover to knew what you have to pass there, you n= eed > > > to look at CONFIG_LSM in kernel config (which will vary across distro= s > > > and also mean copy-paste from the web source may won't work as expect= ed) > > > which again most users don't do. > > > I think there is risk that users will end up with "lsm=3Dselinux" wit= hout > > > realizing that they may disable something along the way. > > > I would prefer for "lsm=3D" to work as override to "CONFIG_LSM=3D" wi= th > > > below assumptions: > > > I. lsm=3D"$lsm" will append "$lsm" at the end of string. Before extre= me > > > stacking it will also remove the other major (explicit) lsm from it. > > > II. lsm=3D"!$lsm" will remove "$lsm" from the string. > > > III. If "$lsm" already exist in the string, it's moved at the end of = it > > > (this will cover ordering). > > > > We've had things sort of like this proposed, but if you can convince > > James and others, I'm all for it. I think the standing objection from > > James and John about this is that the results of booting with > > "lsm=3Dsomething" ends up depending on CONFIG_LSM=3D for that distro. S= o > > you end up with different behaviors instead of a consistent behavior > > across all distros. > > Its certainly a point that could confuse the user. I do have concerns > about it, but not something that is on a must haves list > > > Now, in the future blob and extreme stacking world, having the > > explicit lsm=3D list shouldn't be too bad since LSMs will effectively > > ALL be initialized -- but they'll be inactive since they have no > > policy loaded. > > you are more optimistic about this than I am, but there will be at > least some movement towards this. > > > But I still agree with you: I'd like a friendlier way to > > disable/enable specific LSMs, but an explicit lsm=3D seems to be the > > only way. > > Hrmmm, I don't know about the only way, but a way to provide the > explicit list, and also set a specific set as the default in the > Kconfig is a hard requirement. > My proposition allows for explicit "lsm=3D" list but also accepts non explicit list. This is it's advantage above current approach. The current approach works but it seems to target the very same people who designed it :) > The initial lsm.ebable, lsm.disable had too many issues, and for > various reasons I never managed to get back to kees' proposal > for using +. > > That said, I do think the right approach for the initial pass is > the explicit list. It moves the arguments to the side and allows > this work to move forward. > I'm afraid when it hits stable kernel and people will rely on it, then it will be too late. Things will be even more hard to change than now when we have to keep legacy syntax of security=3Dxxx. I added explanation why explicit list doesn't solve consistency across distros in the other reply > > > It's possible that something lime this was discussed already > > > but without full examples it was hard to me for tracking things. > > > > It's been a painful thread. ;) > > Indeed Jordan