Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3eaa7e1fd74c2cdd4efe63ea8c8249666d046003.camel@linux.ibm.com>
Subject: Re: [PATCH 2/9] security: Move trivial IMA hooks into LSM
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Kees Cook <keescook@chromium.org>
Cc:     Paul Moore <paul@paul-moore.com>, James Morris <jmorris@namei.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
        =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= <mic@digikod.net>,
        Petr Vorel <pvorel@suse.cz>, Borislav Petkov <bp@suse.de>,
        Takashi Iwai <tiwai@suse.de>,
        Jonathan McDowell <noodles@fb.com>,
        linux-security-module@vger.kernel.org,
        linux-integrity@vger.kernel.org, KP Singh <kpsingh@kernel.org>,
        Casey Schaufler <casey@schaufler-ca.com>,
        John Johansen <john.johansen@canonical.com>,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Date:   Thu, 20 Oct 2022 08:17:52 -0400
In-Reply-To: <202210191639.58F18F1AA@keescook>
References: <20221013222702.never.990-kees@kernel.org>
         <20221013223654.659758-2-keescook@chromium.org>
         <16e008b3709f3c85dbad1accb9fce8ddad552205.camel@linux.ibm.com>
         <202210191134.FC646AFC71@keescook>
         <ffa58bb09df15a9debc45aaf0ed51f2b34f5c225.camel@linux.ibm.com>
         <202210191639.58F18F1AA@keescook>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2022-10-19 at 16:41 -0700, Kees Cook wrote:
> On Wed, Oct 19, 2022 at 04:45:41PM -0400, Mimi Zohar wrote:
> > On Wed, 2022-10-19 at 11:59 -0700, Kees Cook wrote:
> > > On Wed, Oct 19, 2022 at 10:34:48AM -0400, Mimi Zohar wrote:
> > > > On Thu, 2022-10-13 at 15:36 -0700, Kees Cook wrote:
> > > > > This moves the trivial hard-coded stacking of IMA LSM hooks into the
> > > > > existing LSM infrastructure.
> > > > 
> > > > The only thing trivial about making IMA and EVM LSMs is moving them to
> > > > LSM hooks.  Although static files may be signed and the signatures
> > > > distributed with the file data through the normal distribution
> > > > mechanisms (e.g. RPM), other files cannot be signed remotely (e.g.
> > > > configuration files).  For these files, both IMA and EVM may be
> > > > configured to maintain persistent file state stored as security xattrs
> > > > in the form of security.ima file hashes or security.evm HMACs.  The LSM
> > > > flexibility of enabling/disabling IMA or EVM on a per boot basis breaks
> > > > this usage, potentially preventing subsequent boots.
> > > 
> > > I'm not suggesting IMA and EVM don't have specific behaviors that need to
> > > be correctly integrated into the LSM infrastructure. In fact, I spent a
> > > lot of time designing that infrastructure to be flexible enough to deal
> > > with these kinds of things. (e.g. plumbing "enablement", etc.) As I
> > > mentioned, this was more of trying to provide a head-start on the
> > > conversion. I don't intend to drive this -- please take whatever is
> > > useful from this example and use it. :) I'm happy to help construct any
> > > missing infrastructure needed (e.g. LSM_ORDER_LAST, etc).
> > > 
> > > As for preventing subsequent boots, this is already true with other LSMs
> > > that save state that affects system behavior (like SELinux tags, AppArmor
> > > policy). IMA and EVM are not special in that regard conceptually.
> > 
> > > Besides, it also looks like it's already possible to boot with IMA or EVM
> > > disabled ("ima_appraise=off", or "evm=fix"), so there's no regression
> > > conceptually for having "integrity" get dropped from the lsm= list at
> > > boot. And if you want it not to be silent disabling, that's fine --
> > > just panic during initialization if "integrity" is disabled, as is
> > > already happening.
> > 
> > Being able to specify "ima_appraise=" on the boot command line requires
> > IMA_APPRAISE_BOOTPARAM to be configured.  Even when specified, if the
> > system is booted with secure-boot mode enabled, it also cannot be
> > modified.   With the ability of randomly enabling/disabling LSMs, these
> > protections are useless.
> 
> Sure, so let's get lsm= added to the lockdown list, etc.

I thought the move to "lsm=" was to allow different LSMs to be
enabled/disabled at run time.  Adding "lsm=" to the lockdown list
doesn't seem like the correct solution to limiting which LSMs can be
enabled/disabled at runtime.  As I recall, lockdown needs to be enabled
by userspace.

> My point is for
> us to work through each of these concerns and address them. I am not an
> IMA/EVM expert, but I do understand the LSM infrastructure deeply, so
> I'd like to help you get these changes made.

Sure

-- 
thanks,

Mimi