linux-kernel - Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACK8Z6EXDf2vUuJbKm18R6HovwUZia4y_qUrTW8ZW+8LA2+RgA@mail.gmail.com>
Date:   Wed, 3 Jun 2020 04:51:18 -0700
From:   Rajat Jain <rajatja@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Rajat Jain <rajatxjain@...il.com>,
        Bjorn Helgaas <helgaas@...nel.org>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Krishnakumar, Lalithambika" <lalithambika.krishnakumar@...el.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-pci <linux-pci@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Prashant Malani <pmalani@...gle.com>,
        Benson Leung <bleung@...gle.com>,
        Todd Broch <tbroch@...gle.com>,
        Alex Levin <levinale@...gle.com>,
        Mattias Nissler <mnissler@...gle.com>,
        Zubin Mithra <zsm@...gle.com>,
        Bernie Keany <bernie.keany@...el.com>,
        Aaron Durbin <adurbin@...gle.com>,
        Diego Rivas <diegorivas@...gle.com>,
        Duncan Laurie <dlaurie@...gle.com>,
        Furquan Shaikh <furquan@...gle.com>,
        Jesse Barnes <jsbarnes@...gle.com>,
        Christian Kellner <christian@...lner.me>,
        Alex Williamson <alex.williamson@...hat.com>,
        Joerg Roedel <joro@...tes.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of
 "whitelisted" drivers

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.
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. 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.

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?

Thanks & Best Regards,

Rajat

> thanks,
>
> greg k-h