Thunderbolt Access Security Implications
Thunderbolt 3 is an upcoming I/O technology that will likely take over as the preferred method of attaching various external devices such as displays, storage devices and others. Unlike USB, TB allows wide access to devices or memory for example. It is speculated that a malicious device could be attached to a PC and copy memory or inject malicious spyware. This has been successfully achieved in the past, over a similar I/O port, Firewire.
- A notebook attached to a projector at a conference. While providing the display capabilities, the malicious device also starts making copy of the hardrive in the background.
- While you leave a notebook in the office, somebody attaches a malicious device to copy data over
User Experience Considerations
Similar to a firewall approach, it would be undesirable to treat every device as potentially harmful in a general case. It renders a machine broken by default. The "do you allow new TB device?" authorization model that is used on Windows offloads the responsibility to authorize a device to the user who might not have experience and enough context to make such decision. It will simply create a hurdle that users will habituate to skip through. An "unbreak my computer" dialog.
Poor Permissions Model
Asking a generic "Do you trust Foobar Inc. Device?" is a simple transfer of responsibility/blame to the user. It doesn't provide specifics of what the device is trying to do. To authorize a device, it should be known what the device is about to do. Rather than asking yes/no authorization questions, specific action by the user could be requested instead. When plugging in a projector, the system could present the display settings panel in presentation mode, requiring explicit enabling of the detected projector. See https://wiki.gnome.org/Design/SystemSettings/Displays
Unless we can prevent the projector to also access system memory or storage devices, a broad device blocking and user driven whitelisting will not be effective against the attack described above.
Activating Thunderbolt can take up to 10 seconds. While it would be desirable to speed up the discovery and security handshake, it's necessary to provide feedback to the user that the hardware is in an intermediate state, similar to connecting to wifi network.
A typical home user running distributions such as Fedora or Ubuntu.
- automatically enable new TB3 devices:
- when the user is administrator
- a session is running (computer isn't locked)
As per use case , when connecting a previously unknown device, when the session is locked the device is not authenticated and a notification is triggered. Once unlocked, the notification hints to reconnect the device to allow it to function properly. Similar notification is triggered when the device is attached before booting the system. New devices require the system to be authorized and running.
FIXME: When the user isn't an admin, don't enable device and notify with option to ask for root pwd?
In a corporate environment where a flat access to i/o is not acceptable, the thunderbolt device access is prohibited. Upon connecting an unknown device that isn't on the whitelist, the user is notified that such device is not allowed and given the option to contact the administrator to white list the device.
FIXME: URL needs to be customized. Do we provide a fallback URI hinting it hasnt been set?
FIXME: centralized ID whitelist; method of submitting metainfo on the device or management tool for the admin to carry around to whitelist a local device and upload device info to the centralized store. Can the whitelist update be carried out using Fleet Commander?