Brno Hat

Jiri Eischmann's Blog

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?

18 responses to “ThunderBolt Security Levels and Linux desktop”

  1. Joe Buck Avatar
    Joe Buck

    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.

    Reply
  2. Kamil Páral Avatar
    Kamil Páral

    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.

    Reply
    1. Maciej Piechotka Avatar
      Maciej Piechotka

      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.

      Reply
  3. Michael Catanzaro Avatar
    Michael Catanzaro

    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.

    Reply
    1. Tobias Mueller Avatar
      Tobias Mueller

      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.

      Reply
    2. foo Avatar
      foo

      It looks like a solution is being worked on:

      https://github.com/dkopecek/usbguard

      Also:
      – http://rhelblog.redhat.com/2017/08/03/built-in-protection-against-usb-security-attacks-with-usbguard/
      – https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using-USBGuard.html

      Reply
      1. foo Avatar
        foo

        There’s also an issue suggesting TB support: https://github.com/dkopecek/usbguard/issues/173

        Reply
  4. Alex Wauck Avatar
    Alex Wauck

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

    Reply
  5. andreasn Avatar
    andreasn

    Great idea with denying when screen is locked!

    Reply
  6. “BIOS settings and set the Thunderbolt Security level to “No securi… | Dr. Roy Schestowitz (罗伊)

    […] "BIOS settings and set the Thunderbolt Security level to “No security”. Then suddenly almost everything is working" https://eischmann.wordpress.com/2017/06/29/thunderbolt-security-levels-and-linux-desktop/ […]

    Reply
  7. hughsient Avatar
    hughsient

    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…

    Reply
  8. Links 1/7/2017: Kubernetes 1.7 and Mesa 17.1.4 Released | Techrights

    […] ThunderBolt Security Levels and Linux desktop […]

    Reply
  9. typhen Avatar
    typhen

    I wonder what happens on systems without an active GUI or with multiple loged in users.

    Reply
  10. Ausblick auf Linux 4.13: Amdgpu-Erweiterungen, Thunderbolt-Sicherheit & TLS im Kernel – Avada Classic

    […] Zur Aufnahme vorgesehen ist auch Code zur Unterstützung des „Internal Connection Manager (ICM)“, der in neuere Thunderbolt-Controllern von Intel steckt. Über ihn lässt sich regulieren, wie viel Berechtigungen die angesteckten Thunderbird-Gerät erhalten. Eine solche Funktion fehlt bislang – letztlich muss man daher eine unsichere Betriebsart aktivieren, um Thunderbolt-Devices unter Linux nutzen zu können. Ein Red-Hat-Entwickler hat erst kürzlich in einem viel beachteten Blog-Eintrag auf diese Problematik hingewiesen. […]

    Reply
  11. Hedayat Avatar
    Hedayat

    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.

    Reply
  12. Alex F. Avatar
    Alex F.

    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.

    Reply
  13. Bolt Will Tackle Thunderbolt 3 Security on Linux – PingIze

    […] the latest Linux kernel has support for these security levels there’s work to be done on integrating them at the desktop level (‘user […]

    Reply
  14. Dualboot mit Windows 10 (Bitlocker) und Arch Linux (LUKS Container) | Timos Blog

    […] Das Security Level muss aber für Linux sowieso herabgesetzt werden, da sonst Geräte an der Dockingstation nicht erkannt werden, bzw. alle Geräte am Thunderbolt nicht erkannt werden (vgl. https://eischmann.wordpress.com/2017/06/29/thunderbolt-security-levels-and-linux-desktop/). […]

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *