> -----Original Message----- > From: Alan Cox [mailto:[email protected]] > Sent: Thursday, October 5, 2017 8:59 AM > To: Limonciello, Mario <[email protected]> > Cc: [email protected]; Andy Shevchenko <[email protected]>; > LKML <[email protected]>; [email protected]; > Andy Lutomirski <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; Greg > KH <[email protected]> > 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 <[email protected]> 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.
