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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <41b7c231-1c97-2196-878b-92ad1778f11c@schaufler-ca.com>
Date:   Thu, 20 Oct 2022 09:00:47 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Kees Cook <keescook@...omium.org>, Paul Moore <paul@...l-moore.com>
Cc:     Nicolas Iooss <nicolas.iooss@....org>,
        Mickaël Salaün <mic@...ikod.net>,
        James Morris <jmorris@...ei.org>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Mickaël Salaün <mic@...ux.microsoft.com>,
        casey@...aufler-ca.com
Subject: Re: [PATCH v3 1/1] security: Add CONFIG_LSM_AUTO to handle default
 LSM stack ordering

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. :)
>