On Friday, December 6, 2019 1:02:04 AM MST Lennart Poettering wrote: > On Do, 05.12.19 16:33, John M. Harris Jr (johnmh@xxxxxxxxxxxxx) wrote: > > > > > Locking down the OS itself and locking down the user's home are two > > > different things, because OS integrity should be bound to different > > > mechanisms than user data encryption. (i.e. OS integrity should be > > > bound to vendor trust or TPM, while user data should be bound to > > > user's security credentials). > > > > > > > > I could not disagree more. That would be fine if the trust were the user > > or the organization that owns the machine, but not vendor trust or > > anything of the like. It's not some third party's system, it's the user > > or organization's. Additionally, it's much easier to get a third party to > > sign something for you than to get the users themselves, or an > > organization, to sign it. > > Humm, so you turn off gpg verification of RPMs you install? Nah, you > don't, because you put trust in Fedora that the RPMs they build are > somewhat safe to use. That's what vendor trust means. Since regular > users (and even very technical ones) cannot personally validate the > trustworthiness of compiled code we outsource that to distributions, > and trust the vendor's benevolence and understanding of things. And > that's the correct way to build integrity for OS resources. Vendor trust for packages are not the same as vendor trust for the boot environment. A better solution for the boot environment, with UX in mind, would be to generate a key for the system at install time, and require that the kernel+initramfs be signed with that key in order to boot. This would prevent individuals, outside of the folks the user has trusted to maintain their kernel image for them, normally the packagers of Fedora's kernel but sometimes Linux-libre or similar, from modifying their boot environment. Even for packages, I don't trust Red Hat's key outright. For example, at $WORK, where we deploy RHEL, we resign using our own GPG keys when we bring in updates, removing things like PackageKit and flatpak. -- John M. Harris, Jr. Splentity _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
