GNOME, Linux

ThunderBolt Security Levels and Linux desktop

Recently I got Dell XPS 13 as my new work laptop and I use it with the TB16 dock. This dock doesn’t seem to fully work with Linux, only monitors work. But if you go to BIOS settings and set the Thunderbolt Security level to “No security”. Then suddenly almost everything is working.

However, it’s not an ideal solution, especially if you’re at least a bit paranoid. External Thunderbolt devices may connect to the machine via PCI-Express which means they can potencially read your system memory. That’s why Thunderbolt comes with a security system.

There are 4 security levels:

  • none (legacy mode): no security, everything gets enabled.
  • dponly: no PCIe tunneling, only USB and DisplayPort.
  • user: ask the user if it is ok to connect the device.
  • secure: as “user” but also create and use a random key that later can be used on subsequent connects of the same device to ensure its identity.

Intel is already working on a Linux implementation of TB security. But the user and secure levels need user’s action, so there will have to be some support for it in the desktop. I discussed that with designers and they don’t really like the idea of poping up dialogs asking users if they trust the device. “Do I trust this projector? I’m not really sure, but since I’m plugging it in, I guess I do”.

I also checked how it works in Windows 10. And it works exactly that way. I plugged in the dock and I got a bunch of dialogs asking about every single plugged-in device. The experience is pretty terrible. And I have to agree with the designers, I’m not sure how this improves security.

On the other hand, I don’t think it’s a good idea to leave the Thunderbolt port completely unprotected. There is one relevant use case: you leave your computer unattanded and even though you locked your screen, someone can access your system through an unsecured TB3 port.

I wonder if it could be solved by automatically switching to a “reject everything” mode once you lock your screen. You lock your screen, leave your computer, and any device plugged into the TB3 port would be rejected. Once you come back and unlock your screen, it’s your responsibility what you plug in and any plugged device would be accepted.

I wonder if there is any relevant use case which would not be covered well by this policy. Any ideas?

Advertisements

15 thoughts on “ThunderBolt Security Levels and Linux desktop

  1. If you are only asked about a given device the first time you plug it in, and are not asked again later on, it’s not too painful, and might make the person who is about to plug in a USB stick he/she found on the ground think a bit before doing it. If the user is asked every time, that’s horrible.

  2. As said above, if this is a one time confirmation, the dialogs should definitely be shown. The message can be descriptive, like “It seems like you just inserted device $DEVICE. Do you want to enable it? The device will have full access to your computer, and malicious devices can steal your data or worse. Only enable trusted devices.”

    Auto-approving devices when having your screen unlocked is a bad idea. You can’t prevent a person just appearing from somewhere, sticking a thumb drive to your usb port and asking “can you please print something for me?”. It’s too late, now your machine can be hacked (and you simply can’t tell). With the confirmation dialog, you can move the thumb stick to a “safe” port (if you know about all this).

    By the way, using ThunderBolt for peripherals sounds like a really bad idea and a broken design on the protocol part. Introducing a technology with which a mouse or a projector can hack your computer really seems like a 1970’s concept, not 2017. Of course we need to deal with it somehow. But I wouldn’t use the “auto-approve” approach.

    1. As usual this is question of usability and security. In this case usability is a question of speed as without access to main memory you cannot do DMA and you are quite limited in what you can do. In particular – no eGPU eNVME etc. Without DMA you need to de-factor use PIO with all the power/speed consequences.

      Incidentally it is quite hard on modern PC to debug kernel as there is no easy way to perform DMA over USB, COM ports are things of the past, FireWire never took off and network is kind of a hack…

      I think correct solution would be IOMMU and disabling access to everything on first use. If user wants to use something he needs to click and confirm (if this requires full PCI-E access). So if the network card requires PCI-E access instead of using DP then user on first time needs to manually enable it in network panel. Even in such case it only have access to buffers etc.

  3. Tangent:

    This reminds me of the major problem we currently have with malicious USB devices. You plug a USB thumb drive into your computer, but it tells the computer that it’s a keyboard and then injects whatever keystrokes it wants and you’re pwned. Or it says it’s a network device and starts transmitting your personal info to the Internet. We could close this entire class of vulnerabilities if we had a prompt to ask the user what type of device was entered. I’m imagining a pop-up with two big buttons, one with a symbolic icon for a keyboard or network device, the other for a USB. And if the user selects USB while the device has reported it’s a keyboard, then we’ve discovered the device is malicious.

    1. I’ve worked on this a little a few years ago. I also had a GSoC student who produced a Shell extension to allow you to turn USB on and off. Needless to say, it also disabled new USB devices except for HIDs while the screensaver was off. That’s the least we should do.
      We must not prompt the user. I’m thinking of a more lenient approach like showing the a symbolic device that the user can turn on and off. Much like we currently do with Bluetooth or WiFi.

  4. As somebody who is very security-conscious and also about to get an XPS 13 at work, I am quite interested in this. I would personally be OK with the “silently accept everything when unlocked, silently reject everything when locked” paradigm. (Although, what happens if something is plugged in while the screen is locked and then the screen is unlocked? Does it have to be unplugged and then plugged back in? Does it just start working?)

    That said, if I ended up using a lot of TB3 devices, I think I would want a pop-up that tells me what kind of device I’ve plugged in (e.g. is it using PCIE?) and gives me an opportunity to reject it (e.g. projector shows up as PCIE device).

  5. I’ve been active on the thunderbolt-linux mailing list; you should see some progress in this space soon hopefully. Check out the archives for the story so far…

  6. I’m OK with rejecting the device when device is locked. But a notification about this rejection is probably useful.

    When unlocked, it might be better to enable the device after some time (e.g. 1 minute), showing a passive notification with a ‘reject’ button so that user can reject it before activation if (s)he wants. Yes, it is not great either, but maybe better than auto-activation. 😛

    And it is probably good to be able to eject the device at any time somehow.

  7. In environments where there is a need for higher security (e.g. banking, healthcare, government) the ability to silently accept connections while the screen is unlocked might not be allowed. That might lead to TB ports being forced disabled in those environments.

    It might be worth considering requiring an active agreement or rejection for each connection in higher security settings while allowing the silent acceptance while the screen is unlocked in less restrictive environments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s