[Lvfs-announce] Improving the security model of the LVFS

Hi all,

There are lots of layers of security in the LVFS and fwupd design,
including restricted account modes, 2FA, and server side AppStream
namespaces. The most powerful one is the so-called vendor-id that the
vendors cannot assign themselves, and is assigned by me when creating
the vendor account on the LVFS. The way this works is that all
firmware from the vendor is tagged with one (or many) vendor-id
strings like =E2=80=9CUSB:0x056A=E2=80=9D which in this case matches the US=
B
consortium vendor assigned ID. Client side, the vendor-id from the
signed metadata is checked against the physical device and the
firmware is updated only if the ID matches. This ensures that
malicious or careless users on the LVFS can never ship firmware
updates for other vendors hardware. About 95% of the relevant vendors
on the LVFS are already locked down with this mechanism.

Some vendors must also have USB vendor IDs that they don=E2=80=99t actually
own, a good example here is for a DFU device like the 8bitdo
controllers. In runtime mode they use the USB-assigned 8bitdo VID, but
in bootloader mode they use a generic VID which is assigned to ARM as
they are using the reference bootloader. This is obviously fine, and
both vendor IDs are added for 8bitdo on the LVFS for this reason.
Another example is where Lenovo is responsible for updating
Lenovo-specific NVMe firmware, but where the NVMe vendor isn=E2=80=99t alwa=
ys
Lenovo=E2=80=99s PCI ID.

Anyway, to the point of this email: I=E2=80=99ve deployed some new
functionality to the LVFS which changes the vendor default from 100%
trusted to completely untrusted. I think I=E2=80=99ve already emailed all t=
he
affected vendor managers, and for most people no further action is
required. The OEMs shipping UEFI firmware should already have a
vendor-id of =E2=80=9C*=E2=80=9D (due to now-fixed client issues) which mea=
ns the
metadata is completely unchanged and this email can be mostly ignored.
I=E2=80=99ll be asking those OEMs to actually do something in about 6 month=
s
time, but relax for now.

If you=E2=80=99re shipping NVMe or USB firmware and you ignored my email, y=
ou
might be getting an install error about the vendor ID being invalid
=E2=80=9Ci.e. you see XXX:NEVER_GOING_TO_MATCH=E2=80=9D in the CLI during =
=E2=80=9Cfwupd
update=E2=80=9D please let me know and I can fix things straight away for y=
ou.
The data I=E2=80=99ll need is the output of =E2=80=9Cfwupdmgr get-devices =
=E2=80=93verbose=E2=80=9D
with your device plugged in. The vendor ID will be of the form
=E2=80=9CUSB:0x1234=E2=80=9D or =E2=80=9CNVME:0x5678=E2=80=9D.

If anyone has comments or concerns, please let me know. In case anyone
is curious this vendor-id behaviour change is mostly due to me not
always onboarding vendors consistently, rather than any security bug
in the architecture. The LVFS has grown amazingly in 2019, and I=E2=80=99m
still humbled by the ongoing success of the project. I hope you all
have a great Christmas.

Richard.