Messages in this thread | | | From | <> | Subject | RE: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface | Date | Thu, 5 Oct 2017 14:22:37 +0000 |
| |
> -----Original Message----- > From: Alan Cox [mailto:gnomes@lxorguk.ukuu.org.uk] > Sent: Thursday, October 5, 2017 8:59 AM > To: Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: dvhart@infradead.org; Andy Shevchenko <andy.shevchenko@gmail.com>; > LKML <linux-kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; > Andy Lutomirski <luto@kernel.org>; quasisec@google.com; > pali.rohar@gmail.com; rjw@rjwysocki.net; mjg59@google.com; hch@lst.de; Greg > KH <greg@kroah.com> > 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@dell.com> 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.
| |