Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default LSM stack ordering

From: Casey Schaufler <casey@schaufler-ca.com>
To: Kees Cook <keescook@chromium.org>, Paul Moore <paul@paul-moore.com>
Cc: "Nicolas Iooss" <nicolas.iooss@m4x.org>,
	"Mickaël Salaün" <mic@digikod.net>,
	"James Morris" <jmorris@namei.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	"Mickaël Salaün" <mic@linux.microsoft.com>,
	casey@schaufler-ca.com
Subject: Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default LSM stack ordering
Date: Thu, 20 Oct 2022 09:00:47 -0700	[thread overview]
Message-ID: <41b7c231-1c97-2196-878b-92ad1778f11c@schaufler-ca.com> (raw)
In-Reply-To: <202210172153.C65BF23D5E@keescook>

On 10/17/2022 10:55 PM, Kees Cook wrote:
> On Mon, Oct 17, 2022 at 09:45:21PM -0400, Paul Moore wrote:
>> The code sorta cares about ordering, at least to the extent that the
>> LSMs will behave differently depending on the ordering, e.g. a LSM
> Right -- this is why I've been so uncomfortable with allowing
> arbitrarily reordering of the LSM list from lsm=. There are orderings we
> know work, and others may have undesirable side-effects. I'd much rather
> the kernel be specific about the order.
>
>> I personally would like to preserve the existing concept where "built"
>> does *not* equate to "enabled" by default.
> Yup, understood. I didn't think I was going to win over anyone on that
> one, but figured I'd just point it out again. ;)
>
>>> I *still* think there should be a way to leave ordering alone and have
>>> separate enable/disable control.
>> My current opinion is that enabling a LSM and specifying its place in
>> an ordered list are one in the same.  The way LSM stacking as
>> currently done almost requires the ability to specify an order if an
>> admin is trying to meet an security relevant operation visibility
>> goal.
> As in an admin wants to see selinux rejections instead of loadpin
> rejections for a blocked module loading?
>
> Hmmm. Is this a realistic need?

One of the security modules I hope to write someday will provide controls
based on multiple successful accesses to particular resources. The old
school example is a program that scans /tmp constantly. No one access will
be denied, but the fact that it does stat() on /tmp/foo a thousand times
a second is suspicious. If my system is running any of SELinux, Smack or
AppArmor I may get different results depending on whether it is loaded
before or after the "primary" module. The user may care which result is
obtained. In truth, the user may use the module both ways as a mechanism
to measure the effectiveness of the "primary" module.

The current set of new security modules is diverging from the MAC model
that LSM was invented to support. I don't see that restricting its use
to make the infrastructure easier to deal with (as much as I'd like to
do that from time to time) would be the Right Thing.

>
>> We can have defaults, like we do know, but I'm in no hurry to remove
>> the ability to allow admins to change the ordering at boot time.
> My concern is with new LSMs vs the build system. A system builder will
> be prompted for a new CONFIG_SECURITY_SHINY, but won't be prompted
> about making changes to CONFIG_LSM to include it.
>
> Even booting with "lsm.debug" isn't entirely helpful to helping someone
> construct the "lsm=" option they actually want... I guess I can fix that
> part, at least. :)
>