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(a)splentity.com>
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(a)splentity.com>
>
>
>
> > > 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.