Hi Greg, Thanks for looking into this thread. On Wed, Jun 3, 2020 at 5:16 AM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote: > > Hello, > > > > > > > > > Thanks for the pointer! I'm still looking at the details yet, but a > > > > quick look (usb_dev_authorized()) seems to suggest that this API is > > > > "device based". The multiple levels of "authorized" seem to take shape > > > > from either how it is wired or from userspace choice. Once authorized, > > > > USB device or interface is authorized to be used by *anyone* (can be > > > > attached to any drivers). Do I understand it right that it does not > > > > differentiate between drivers? > > > > > > Yes, and that is what you should do, don't fixate on drivers. Users > > > know how to control and manage devices. Us kernel developers are > > > responsible for writing solid drivers and getting them merged into the > > > kernel tree and maintaining them over time. Drivers in the kernel > > > should always be trusted, ... > > > > 1) Yes, I agree that this would be ideal, and this should be our > > mission. I should clarify that I may have used the wrong term > > "Trusted/Certified drivers". I didn't really mean that the drivers may > > be malicious by intent. What I really meant is that a driver may have > > an attack surface, which is a vulnerability that may be exploited. > > Any code has such a thing, proving otherwise is a tough problem :) > > > Realistically speaking, finding vulnerabilities in drivers, creating > > attacks to exploit them, and fixing them is a never ending cat and > > mouse game. At Least "identifying the vulnerabilities" part is better > > performed by security folks rather than driver writers. > > Are you sure about that? It's hard to prove a negative :) > > > Earlier in the > > thread I had mentioned certain studies/projects that identified and > > exploited such vulnerabilities in the drivers. I should have used the > > term "Vetted Drivers" maybe to convey the intent better - drivers that > > have been vetted by a security focussed team (admin). What I'm > > advocating here is an administrator's right to control the drivers > > that he wants to allow for external ports on his systems. > > That's an odd thing, but sure, if you want to write up such a policy for > your systems, great. But that policy does not belong in the kernel, it > belongs in userspace. Agree. > > > 2) In addition to the problem of driver negligences / vulnerabilities > > to be exploited, we ran into another problem with the "whitelist > > devices only" approach. We did start with the "device based" approach > > only initially - but quickly realized that anything we use to > > whitelist an external device can only be based on the info provided by > > *that device* itself. So until we have devices that exchange > > certificates with kernel [1], it is easy for a malicious device to > > spoof a whitelisted device (by presenting the same VID:DID or any > > other data that is used by us to whitelist it). > > > > [1] https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html > > > > I hope that helps somewhat clarify how / why we reached here? > > Kind of, I still think all you need to do is worry about controlling the > devices and if a driver should bind to it or not. Agree. That is precisely what this RFC had in mind: (1) controlling whether a device is authorized and if so (2) What drivers can bind to it. > Again, much like USB > has been doing for a very long time now. The idea of "spoofing" ids > also is not new, and has been around for a very long time as well, and > again, the controls that the USB core gives you allows you to make any > type of policy decision you want to, in userspace. > > So please, in summary: > - don't think this is some new type of thing, it's an old issue > transferred to yet-another-hardware-bus. Not to say this is > not important, just please look at the work that others have > done in the past to help mitigate and solve this (reading the > Wireless USB spec should help you out here too, as they > detailed all of this.) > - do copy what USB did, by moving that logic into the driver > core so that all busses who want to take advantage of this > type of functionality, easily can do so. Understood, will keep that in mind. I may first present a "PCI subsystem only" draft just to get a feel for it, since that is more familiar to me and also already has some bits and pieces we need for this. Thanks & Best Regards, Rajat > > thanks, > > greg k-h
