> -----Original Message----- > From: Alan Cox [mailto:gnomes@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, October 5, 2017 8:59 AM > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx> > Cc: dvhart@xxxxxxxxxxxxx; Andy Shevchenko <andy.shevchenko@xxxxxxxxx>; > LKML <linux-kernel@xxxxxxxxxxxxxxx>; platform-driver-x86@xxxxxxxxxxxxxxx; > Andy Lutomirski <luto@xxxxxxxxxx>; quasisec@xxxxxxxxxx; > pali.rohar@xxxxxxxxx; rjw@xxxxxxxxxxxxx; mjg59@xxxxxxxxxx; hch@xxxxxx; Greg > KH <greg@xxxxxxxxx> > Subject: Re: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce > userspace interface > > On Wed, 4 Oct 2017 17:48:39 -0500 > Mario Limonciello <mario.limonciello@xxxxxxxx> wrote: > > > This userspace character device will be used to perform SMBIOS calls > > from any applications. > > > > It provides an ioctl that will allow passing the 32k WMI calling > > interface buffer between userspace and kernel space. > > What is your security model for firing 32K of random crap at the BIOS ? Adding new class and select methods requires a review with the security team. They will do STRIDE analysis and threat modeling. > Do you fuzz test the BIOS interface ? Yes there has been internal fuzz testing classes and selects used in the ACPI interface in the past. I can't comment on how regularly that is done. I do think it's interesting is to use the interface in Linux for further fuzz testing though. > > How do we know that between now and the end of the universe every call is > safe to execute as any random user without upsetting other users on the > same PC ? Any random user shouldn't be executing the ioctl. Only root should be executing any of these calls. If there is a particular call that is deemed too dangerous to have available the ioctl call can be filtered by the kernel module. > > Right now this patch is scary. U've fuzzed tested BIOS firmware in thepast > and it almost universally ended up in reaching for the power cord because > PC firmware is usually closed and usually crap. > Can you please share more context? > In addition you are assuming that every function you ever provide via > that ioctl has the same securiy model. So if one of them should only be > usable by the user logged in on the console the system would have to > enforce that for all. If you have two conflicting security policies we'd > have to make it root only and owned by a daemon. If a BIOS turns out to > have a hole then we have to make it CAP_SYS_RAWIO. > > /dev/dorandomvendorspecificshit is not an API and not a security policy. > > Alan All functionality offered through this interface has the same security model. This should only be made available to root, but I don't see the need for a daemon to further sit between calls. The two applications that I see using this in the short term (fwupd and fwupdate) both run as root and would directly use this interface.
