The Tails configuration seems to be:
Allow all devices that are already connected when the daemon starts
If I am not mistaken, that means if a BadUSB such as a mass storage device also having a hidden keyboard is connected when Tails is booting, that device would be permitted.
I’ve searched the Tails website.
site:https://tails.net/ usbguard
I haven’t found any documentation by Tails on USBGuard. Related documentation:
I found some noteworthy Tails tickets.
Something to be considered.
At time of writing, we have the same issue. Consideration on how to fix this below. [1]
There may be a misunderstanding on your side or my side here.
usbguard-notifier is not sudo and does not give account user general sudo/root privileges in user session.
The usbguard daemon runs as root and exposes an IPC interface. Kicksecure adds an IPCAccessControl rule that says “users in this group are allowed to tell usbguard to accept/reject a device.” The daemon enforces that itself.
So the desktop user only gets a narrow capability (authorize/reject USB devices). Not full sudo/root.
For example, a malicious keyboard could always inject extra malicious keystrokes. I.e. inject a unicode character that makes the text that follows invisible, then inject malicious commands to install malware.
Expanded USBGuard, Limitations just now:
USBGuard is a device-level gate, not a keystroke-level firewall. Once you have decided “this is a keyboard, and I will allow it,” the operating system intentionally trusts it exactly like a real human typing. At that point:
- it can send any keystrokes,
- including weird Unicode/control sequences,
- including opening a terminal and pasting a malicious payload.
USBGuard can help before that point (by refusing extra/composite/suspicious HIDs, or “second keyboard” devices). It cannot help after you have allowed a malicious keyboard.
The only protection is “do not allow the wrong keyboard be accepted in the first place”. “Accept a malicious keyboard and hope USBGuard filters bad keystrokes” is impossible.
Related:
Back to your scenario.
- Charging cable:
- In a good case, that should be invisible and only show up as the device that is actually connected to it.
- In a bad case, it’s emulates a second keyboard.
- Adapter: Same as above.
- mass storage: If one USB keyboard is already connected before one plugs in a BadUSB that pretends to be mass storage but also has a hidden keyboard - and suppose our USBGuard rules are set up correctly, then that hidden keyboard interface will be rejected.
[1] Let’s suppose a user is using their notebooks internal keyboard (not USB) only but unknowingly has a BadUSB mass storage device that also comes with a hidden keyboard connected at boot time.
How to prevent this?
Default configuration could disallow all USB devices by default unless explicitly, manually allowed by the user.
That wouldn’t work if the notebook internal keyboard is USB based. In that case, we would have to allow 1 USB keyboard at boot time. Can probably be scripted.
But even if we had this. For best protection, the user would then have to review their USB devices and create their own configuration file. The user would need to have advanced knowledge about USBGuard.
But if the user has advanced knowledge of USBGuard does really our existing configuration get into the way?
This is a clear case of Security versus Usability / Reasonable Security.
This is exactly the security vs. usability point: a distribution default has to stay usable for people who just plug in keyboards, mice, webcams, storage. An expert user who’s worried about mail-swapped cables can (and should) tighten the rules to “no HID at boot except this exact device.”