[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 4 Jan 2017 00:34:04 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, Matthew Garrett <mjg59@...eos.com>,
Ulf Hansson <ulf.hansson@...aro.org>, Mauro Carvalho Chehab <mchehab@...nel.org>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>, Lukas Wunner <lukas@...ner.de>,
Madalin Bucur <madalin.bucur@....com>, Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>, Russell King <rmk+kernel@....linux.org.uk>,
Petr Tesarik <ptesarik@...e.com>, Linux PM <linux-pm@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH] Allow userspace control of runtime disabling/enabling of
driver probing
On Tue, Jan 3, 2017 at 11:58 PM, Kees Cook <keescook@...omium.org> wrote:
> From: Matthew Garrett <mjg59@...eos.com>
>
> Various attacks are made possible due to the large attack surface of
> kernel drivers and the easy availability of hotpluggable hardware that can
> be programmed to mimic arbitrary devices. This allows attackers to find a
> single vulnerable driver and then produce a device that can exploit it by
> plugging into a hotpluggable bus (such as PCI or USB). This violates user
> assumptions about unattended systems being secure as long as the screen
> is locked.
>
> The kernel already has support for deferring driver binding in order
> to avoid problems over suspend/resume. By exposing this to userspace we
> can disable probing when the screen is locked and simply reenable it on
> unlock.
>
> This is not a complete solution - since this still permits device
> creation and simply blocks driver binding, it won't stop userspace
> drivers from attaching to devices and it won't protect against any kernel
> vulnerabilities in the core bus code. However, it should be sufficient to
> block attacks like Poisontap (https://samy.pl/poisontap/).
It also looks like this may be worked around by tricking the user to
unlock the screen while the malicious device is still attached to the
system.
If that really is the case, I wonder if it's worth the extra complexity.
Thanks,
Rafael
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
