On Wednesday, June 3, 2020 12:08:44 AM MST Chris Murphy wrote: > On Wed, Jun 3, 2020 at 12:18 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > wrote: > > > > > > On Tuesday, June 2, 2020 10:52:07 PM MST Chris Murphy wrote: > > > > > On Tue, Jun 2, 2020 at 8:42 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > > > > > > > > > > If kernel lockdown is what disables this, we should look at fixing > > > > kernel > > > > lockdown so that it doesn't break hibernation. This is definitely a > > > > security decision that we shouldn't be imposing on the masses > > > > needlessly, in my opinion. > > > > > > > > > > > > > > > Instead you propose imposing a loophole for attackers to easily deploy > > > malware needlessly. Do you really not see how this is an untenable > > > position for Fedora? > > > > > > > > In my opinion, the threat model you're proposing here is absurd. If people > > can create a valid kernel image that will be loaded from a LUKS > > container, we have bigger problems. > > > Disk encryption isn't enabled by default. The no encryption case > obviously has to be considered. In my opinion, it's already considered. With no disk encryption, it could work just as it does on every system without Secure Boot. > And if it's enabled, the more likely attack vector is sabotage to > induce a crash or corrupt user data, rather than malware injection. > Since you don't know the nature of the attack, and neither do I, > neither one of us knows when the corruption manifests or how. That would require physical access to begin with, and there are much more interesting things you can do once you have physical access. On all desktop systems I've used both personally and in enterprise rollouts, there are pins you can short to give yourself access to the firmware configuration. Even where there's "intrusion detection" and similar here, you can just delete those records after getting in. At that point, you could replace any point of the boot process, even potentially putting something like your own ME/AMT in. Laptops often have pads that function in the same way. The physical access requirement to abuse this means that it'd only affect specific enterprise clients, and generally would not be in the threat model of end users of Fedora. Once you have physical access, you can do a lot with any system. > I also don't know all of the threat models the upstream developers are > accounting for. Did you read all of the referenced lkml emails? Do you > understand why there's a preference for AES-GCM, why they want to > secure the encryption key in the TPM, and why they want to use TPM > localities? And why they wanted it all simplified as well? Which, I > think is sortof funny actually because none of it is very simple. If > you understand those concerns and still have questions, you might > consider directing your concerns upstream. I don't understand why, or where, there's a preference for AES-GCM. If you're talking about using that for the boot image, you're just putting another key the user is going to have to enter in front of them, which you've previously complained about. Simply placing the key in the TPM is a bad idea, because that leads to the exact same issue described above with physical access. While it's true some implementations wipe the TPM when you reset the boot firmware's settings, most do not. At that point, you've got the key from the TPM, you've got the key needed to decrypt the image and you're now able to get to the data on that system. -- John M. Harris, Jr. _______________________________________________ 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
