Re: Supporting hibernation in Workstation ed., draft 1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux