GNOME Bugzilla – Bug 793012
thunderbolt: new panel for thunderbolt devices
Last modified: 2018-04-12 09:22:00 UTC
Thunderbolt is a new IO technology to connect peripherals to the computer. Thunderbolt version 3 has new built in security levels, which also require devices to be authorized. More details and the design for UI/UX here: https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess During the implementation, the following problem came up: if devices could not be authorized because the computer was locked, we issue a notification to the user; but: 1) there is not much space to put a descriptive text, especially once the popup-message is gone. 2) the message is not actionable, i.e. clicking on it does nothing. To mitigate, and also give the user more control over thunderbolt device management, a new thunderbolt device panel has been implemented. It lists devices, shows device and global warnings. Also there is an advanced setting that can put the system daemon into a higher security mode, where a password is always required for new devices. This came up often in discussions as something people would like to activate during conferences. panel code: https://gitlab.gnome.org/gicmo/gnome-shell/tree/wip/thunderbolt/
Created attachment 367596 [details] Multiple devices connected
Created attachment 367597 [details] Page when the daemon is not available
Created attachment 367598 [details] Page when there are no devices connected or stored
Created attachment 367599 [details] Device details dialog
Created attachment 367600 [details] Page with a device missing authorization That is what one would see after a click on the notification of a missing device authorization.
Created attachment 367601 [details] Device dialog with missing authorization
Created attachment 367602 [details] Page with warning of low thunderbolt controller security If we detect that the thunderbolt is in low or no security mode we issue a warning. An open question is: on legacy system (thunderbolt 1/2) we only have "none", i.e. no security. Shall we warn there too? Or detect that situation and not warn then?
Created attachment 367603 [details] Dialog to set the hightened security mode Hidden (on purpose) behind the hamburger menu on the main page.
Created attachment 367604 [details] Page when in heightened security mode
Setting the ui-review keyword. There are a few thunderbolt icons missing. One open question for the device list: shall we have some indication (icon, text) if a device is stored locally or not? There are a few situation where currently the text does not communicate it. Also should the authorization level (with key, without key) be communicated via an icon?
(In reply to Christian Kellner from comment #0) > panel code: https://gitlab.gnome.org/gicmo/gnome-shell/tree/wip/thunderbolt/ It is here: https://gitlab.gnome.org/gicmo/gnome-control-center/tree/thunderbolt
As mentioned on IRC: - Can you use the Adwaita theme please when making screenshots? Makes it hard to compare otherwise - You can probably remove most of the details in the devices properties window, as they're not relevant to end-users - The "security" wording and functionality is probably too involved, I don't understand what most of it means, and linking to documentation is unlikely to help. Is this something that's even in users' hands?
I watched https://www.youtube.com/watch?v=_oLSrNYDAlY so I'm a little more clued in. - Is there any reason why we'd want boltd to be in any mode other than "Heightened security"? There only seems to be 2 modes available from the UI, one which will ask for the admin password, and one that will just enable all devices. Given the security risks, why don't we default to the former, and users that want the latter can use boltctl or "sudo vi" to change that setting? If we went that way, you'd only show the warning icon if the mode is anything but the strictest. - I don't understand the need to say "securely connected". I think you'd only want devices to either be connected securely (eg. connected) or not connected. Ditto for "authorized". - Most of the properties seem to only be useful as a debugging tool. I would make those properties print out when the device is clicked on in the UI, using g_debug() so it would appear in "gnome-control-center -v" - I wouldn't show a "please re-plug" message, but instead a button to allow connecting the device. It would ask the user for the password at that point. In short, remove the 2 separate security modes, remove the use of "authorization" and "securely", and allow connecting to devices without unplugging/replugging.
(In reply to Bastien Nocera from comment #13) > I watched https://www.youtube.com/watch?v=_oLSrNYDAlY so I'm a little more > clued in. One major thing that I completely missed is that the "Security levels" aren't something we change in the kernel or in user-space. They're BIOS settings. Which changes quite a lot of things :/ > - Is there any reason why we'd want boltd to be in any mode other than > "Heightened security"? There only seems to be 2 modes available from the UI, > one which will ask for the admin password, and one that will just enable all > devices. Given the security risks, why don't we default to the former, and > users that want the latter can use boltctl or "sudo vi" to change that > setting? > If we went that way, you'd only show the warning icon if the mode is > anything but the strictest. This isn't possible, because we'll just have to live with whatever mode the BIOS gives us. > - I don't understand the need to say "securely connected". I think you'd > only want devices to either be connected securely (eg. connected) or not > connected. Ditto for "authorized". Most of those are terms that we came up with (the vocabulary to use isn't defined in a standard, and there's very little prior art), and they correspond to what the security level was when the device was plugged in. Because those are purely informative, and can't be changed on a per device basis, I would move the information about those to the Properties dialogue. Something like "Security level" with values of "None" (for the None level), "Remembered" (for "User") and "Trusted" ("Secure mode"). I'm also guessing this can be combined with information about whether the device is connected and active. For example: Connected: Yes/No/Cable plugged in (button to connect here?) maybe. > - Most of the properties seem to only be useful as a debugging tool. I would > make those properties print out when the device is clicked on in the UI, > using g_debug() so it would appear in "gnome-control-center -v" In the properties, you could have the device name (in a way that can be copy/pasted), maybe a way to rename the device ("Dock - Home"). We also have the Security level above which should cover most questions about future behaviour and security. I would hide the UUID (and if challenged, will take photos of all the labels of Bluetooth devices with Bluetooth addresses on them). > - I wouldn't show a "please re-plug" message, but instead a button to allow > connecting the device. It would ask the user for the password at that point. This seems technically possible, and something we'd want to do in the Settings. This doesn't change the current interaction model in the Shell (though we could allow opening the panel from the notification...). I wouldn't use warning icons in the UI, but present the current behaviour when devices are plugged in. The warnings are scary, and because there's no way to fix them or avoid them, not needed. I would however point to the BIOS settings (and here it would be great to be able to reboot to the BIOS...). Finally, I didn't understand the "Heightened security" at all. Could this be labelled as "Allow users to plug in Thunderbolt devices", defaulting to "yes"? Maybe this needs a second switch to allow users to plug/connect/authorise those devices without inputing a password? Last comment. If a user plugs a device in, but only admins are allowed, I'd expect to see a password window asking for an admin password.
I'm sorry about being late with the details on the settings panel. I hopefully addressed some of the concerns Bastien brought up and hopefully avoided exposing the mad "security modes" while allowing to set the TB3 chip to the safer USB+DP mode for travel (in teh OS rather than BIOS). https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess What's missing is communicating a restrictive BIOS setting.
The discussion has moved to: https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/22