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  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]
Date:   Wed, 19 Oct 2022 16:41:24 -0700
From:   Kees Cook <>
To:     Mimi Zohar <>
Cc:     Paul Moore <>, James Morris <>,
        "Serge E. Hallyn" <>,
        Dmitry Kasatkin <>,
        Mickaël Salaün <>,
        Petr Vorel <>, Borislav Petkov <>,
        Takashi Iwai <>,
        Jonathan McDowell <>,,, KP Singh <>,
        Casey Schaufler <>,
        John Johansen <>,,
Subject: Re: [PATCH 2/9] security: Move trivial IMA hooks into LSM

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

Kees Cook

Powered by blists - more mailing lists