From: John Johansen <john.johansen@canonical.com>
To: Jordan Glover <Golden_Miller83@protonmail.ch>,
Kees Cook <keescook@chromium.org>
Cc: James Morris <jmorris@namei.org>,
Casey Schaufler <casey@schaufler-ca.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
Paul Moore <paul@paul-moore.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Randy Dunlap <rdunlap@infradead.org>,
LSM <linux-security-module@vger.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH security-next v5 00/30] LSM: Explict ordering
Date: Thu, 11 Oct 2018 17:26:35 -0700 [thread overview]
Message-ID: <1a8ac9f4-8f82-5d3b-46ef-08801793443e@canonical.com> (raw)
In-Reply-To: <37rRa7F7i2XcwVPiT6gLC8cX8p0732iDiT6mGjstlbBi3mcJsQCLA6A8HcDMNjR0SGheErloJl8z-Z5c57XxtJRBF9-LO_fUTUf41EcAGC4=@protonmail.ch>
On 10/11/2018 04:53 PM, Jordan Glover wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 12, 2018 1:09 AM, Kees Cook <keescook@chromium.org> wrote:
>
>> 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=something" ends up depending on CONFIG_LSM= for that distro. So
>> you end up with different behaviors instead of a consistent behavior
>> across all distros.
>>
>
> Ok, I'll try :)
>
> The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot
> param "lsm=". Changing even only one of those parts also changes the
> final string.
>
> In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm="
> stays constant, the behavior will be different, example:
>
> Distro A has: CONFIG_LSM=loadpin,integrity,selinux
> Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux
>
> User on distro A wants to enable apparmor with:
>
> lsm=loadpin,integrity,apparmor
>
> which they do and add it to howto on wiki.
>
> User on distro B want to enable apparmor, they found info on some wiki and do:
>
> lsm=loadpin,integrity,apparmor
>
>
> Puff, yama got disabled!
>
> Above example shows why I think "consistent behavior across all distros"
> argument for current approach is flawed - because distros aren't
> consistent. In my proposition the user will just use "lsm=apparmor" and
> it will consistently enable apparmor on all distros which is what they
> really wanted, but all pre-existing differences across distros will
> remain unchanged.
Are you sure about that? I have had more than one question about
security=X resulting in a system with more than just X enabled. Ie why
is yama enabled when I specifically set security to X.
There will certainly be cases where what you describe is exactly what
the user wants. The problem is an explosion of options isn't good
for the user either.
What I want at the moment is the discussion about different ways to
enable LSMs to be split off so this work can move forward.
>
> The current approach requires that everyone who dares to touch "lsm="
> knows about existence of all lsm, their enabled/disabled status on
> target distro and their order. I doubt there are many people other
> than recipients of this mail who fit for the above.
>
Without having gotten a chance to review the current set of patches
that was not what was discussed, it should only requires they know the
set that they want.
It is possible some of the LSMs in the list are not available for a
given kernel, but that is a problem with even the additive approach.
That is
lsm=+apparmor
will not add apparmor to the set of LSMs available at run time if
apparmor has not been built into the kernel.
> I it's better to assume that average user has rather vague knowledge
> about lsm and don't delve deep into Kconfig's of their chosen distro.
> If they want to use "lsm=" their goal is to disable/enable on or more
> things. My proposition will work better for those. More advanced users
> still will may pass any "lsm=" string as they like, this having full
> control.
>
> Jordan
>
next prev parent reply other threads:[~2018-10-12 0:26 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 0:18 [PATCH security-next v5 00/30] LSM: Explict ordering Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 01/30] LSM: Correctly announce start of LSM initialization Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 02/30] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 03/30] LSM: Rename .security_initcall section to .lsm_info Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 04/30] LSM: Remove initcall tracing Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 05/30] LSM: Convert from initcall to struct lsm_info Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 06/30] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 07/30] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 08/30] LSM: Record LSM name in struct lsm_info Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 09/30] LSM: Provide init debugging infrastructure Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 10/30] LSM: Don't ignore initialization failures Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 11/30] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 12/30] LSM: Provide separate ordered initialization Kees Cook
2018-11-02 18:13 ` Mimi Zohar
2018-11-02 20:49 ` Kees Cook
2018-11-05 14:13 ` Mimi Zohar
2018-10-11 0:18 ` [PATCH security-next v5 13/30] LoadPin: Rename boot param "enabled" to "enforce" Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 14/30] LSM: Plumb visibility into optional "enabled" state Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 15/30] LSM: Lift LSM selection out of individual LSMs Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 16/30] LSM: Build ordered list of LSMs to initialize Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 17/30] LSM: Introduce CONFIG_LSM Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 18/30] LSM: Introduce "lsm=" for boottime LSM selection Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 19/30] LSM: Tie enabling logic to presence in ordered list Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 20/30] LSM: Prepare for reorganizing "security=" logic Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 21/30] LSM: Refactor "security=" in terms of enable/disable Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 22/30] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 23/30] apparmor: Remove SECURITY_APPARMOR_BOOTPARAM_VALUE Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 24/30] selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 25/30] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 26/30] LSM: Split LSM preparation from initialization Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 27/30] LoadPin: Initialize as ordered LSM Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 28/30] Yama: " Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 29/30] LSM: Introduce enum lsm_order Kees Cook
2018-10-11 0:18 ` [PATCH security-next v5 30/30] capability: Initialize as LSM_ORDER_FIRST Kees Cook
2018-10-11 3:45 ` [PATCH security-next v5 00/30] LSM: Explict ordering James Morris
2018-10-11 15:14 ` Kees Cook
2018-10-11 15:52 ` James Morris
2018-10-11 17:57 ` Kees Cook
2018-10-11 22:58 ` Jordan Glover
2018-10-11 23:09 ` Kees Cook
2018-10-11 23:48 ` John Johansen
2018-10-12 0:11 ` Jordan Glover
2018-10-12 1:19 ` John Johansen
2018-10-12 11:31 ` Jordan Glover
2018-10-12 18:24 ` John Johansen
2018-10-12 19:01 ` Kees Cook
2018-10-23 16:48 ` Casey Schaufler
2018-10-23 18:50 ` Kees Cook
2018-10-23 19:05 ` Casey Schaufler
2018-10-24 8:56 ` Casey Schaufler
2018-10-24 20:12 ` Kees Cook
2018-11-14 21:04 ` Casey Schaufler
2018-11-20 23:36 ` Casey Schaufler
2018-10-11 23:53 ` Jordan Glover
2018-10-12 0:26 ` John Johansen [this message]
2018-10-12 11:31 ` Jordan Glover
2018-10-12 18:11 ` John Johansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a8ac9f4-8f82-5d3b-46ef-08801793443e@canonical.com \
--to=john.johansen@canonical.com \
--cc=Golden_Miller83@protonmail.ch \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rdunlap@infradead.org \
--cc=sds@tycho.nsa.gov \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).