On Wed, Jun 3, 2020 at 9:37 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > On Wednesday, June 3, 2020 12:08:44 AM MST Chris Murphy wrote: > > 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. Physical access is the topic. That is indicated in a UEFI Secure Boot context as it's intended to protect against evil maid attack. While bootloader malware (or bootkits) aren't only deployed by physical access, it's perhaps Exhibit 1 example wise anyway. > 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. UEFI Secure Boot doesn't prevent you from gaining access to firmware setup. It can cause some options in firmware setup to become unavailable, e.g. compatibility support modules for presenting a legacy BIOS. I'm skeptical that pin shorts permit you to gain access to such things - but if so, it's clearly a vulnerability that should be reported. > 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. The authenticated encryption of the hibernation image is concerned about specific attacks. As I said already, I don't know all of the attacks the designers are trying to mitigate. But I expect they aren't concerned with all possible attacks, rather the specific ones in the domain they can mitigate: pilfering the hibernation image and extracting secrets; modification of the image to corrupt it or cause corruption while in use in unsuspecting ways. But probably they are not concerned about the image being restored in a particular sequence of events to that same machine whereby the information decrypted by the resume process should be protect by other systems - not the AE hibernation image scheme. No one has the key from the TPM, that is not correct - it's unsealed in certain cases and provided to the kernel - if the attacker has that key for some reason then some other aspect of security has failed. It is not the responsibility of one protection scheme to protect against all attacks simultaneously. Just like it is not the responsibility of the AE hibernation image scheme to ensure login authentication to a desktop shell. -- Chris Murphy _______________________________________________ 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
