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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 20 Oct 2022 08:17:52 -0400 From: Mimi Zohar <zohar@...ux.ibm.com> To: Kees Cook <keescook@...omium.org> Cc: Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Dmitry Kasatkin <dmitry.kasatkin@...il.com>, Mickaël Salaün <mic@...ikod.net>, Petr Vorel <pvorel@...e.cz>, Borislav Petkov <bp@...e.de>, Takashi Iwai <tiwai@...e.de>, Jonathan McDowell <noodles@...com>, linux-security-module@...r.kernel.org, linux-integrity@...r.kernel.org, KP Singh <kpsingh@...nel.org>, Casey Schaufler <casey@...aufler-ca.com>, John Johansen <john.johansen@...onical.com>, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH 2/9] security: Move trivial IMA hooks into LSM 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
Powered by blists - more mailing lists