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
| ||
|
Date: Tue, 11 Jan 2022 21:26:44 +0000 From: Eric Snowberg <eric.snowberg@...cle.com> To: Mimi Zohar <zohar@...ux.ibm.com> CC: David Howells <dhowells@...hat.com>, "dwmw2@...radead.org" <dwmw2@...radead.org>, "ardb@...nel.org" <ardb@...nel.org>, Jarkko Sakkinen <jarkko@...nel.org>, "jmorris@...ei.org" <jmorris@...ei.org>, "serge@...lyn.com" <serge@...lyn.com>, "nayna@...ux.ibm.com" <nayna@...ux.ibm.com>, "keescook@...omium.org" <keescook@...omium.org>, "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>, "weiyongjun1@...wei.com" <weiyongjun1@...wei.com>, "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>, "linux-security-module@...r.kernel.org" <linux-security-module@...r.kernel.org>, "James.Bottomley@...senpartnership.com" <James.Bottomley@...senPartnership.com>, "pjones@...hat.com" <pjones@...hat.com>, Konrad Wilk <konrad.wilk@...cle.com> Subject: Re: [PATCH v9 2/8] integrity: Introduce a Linux keyring called machine > On Jan 11, 2022, at 11:16 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote: > > On Mon, 2022-01-10 at 23:25 +0000, Eric Snowberg wrote: >>> Jarkko, my concern is that once this version of the patch set is >>> upstreamed, would limiting which keys may be loaded onto the .machine >>> keyring be considered a regression? >> >> >> Currently certificates built into the kernel do not have a CA restriction on them. >> IMA will trust anything in this keyring even if the CA bit is not set. While it would >> be advisable for a kernel to be built with a CA, nothing currently enforces it. >> >> My thinking for the dropped CA restriction patches was to introduce a new Kconfig. >> This Kconfig would do the CA enforcement on the machine keyring. However if the >> Kconfig option was not set for enforcement, it would work as it does in this series, >> plus it would allow IMA to work with non-CA keys. This would be done by removing >> the restriction placed in this patch. Let me know your thoughts on whether this would >> be an appropriate solution. I believe this would get around what you are identifying as >> a possible regression. > > True the problem currently exists with the builtin keys, but there's a > major difference between trusting the builtin keys and those being > loading via MOK. This is an integrity gap that needs to be closed and > shouldn't be expanded to keys on the .machine keyring. > > "plus it would allow IMA to work with non-CA keys" is unacceptable. Ok, I’ll leave that part out. Could you clarify the wording I should include in the future cover letter, which adds IMA support, on why it is unacceptable for the end-user to make this decision?
Powered by blists - more mailing lists