Bug 82369 - RFE: option to lock USB ports when no session is opened
Summary: RFE: option to lock USB ports when no session is opened
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-08 20:57 UTC by Yves-Alexis
Modified: 2015-02-19 21:56 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Yves-Alexis 2014-08-08 20:57:11 UTC
Hi,

following the various presentation on USB security (for example the “Bad USB” one at Black Hat 2014 [1], but actually there quite some more earlier, like Travis Goodspeed experiments with the facedancer [2] etc.) and a thread on oss-security [3], came the idea to “lock” the USB ports in the kernel when the systems is locked [4,5]. This can be done by setting the usbcore.authorized_default parameter to 0 [6].

I guess logind/systemd would be able to do things like that?

There's a caveat, since it could be possible to lock yourself out, for example if you lock your screen, or log out from your session, and unplug your USB keyboard. There's also the boot situation, but maybe USB could be enabled for the first few minutes then disabled.

Grsecurity also has a feature to disable new USB devices (either after boot or after toggling a sysctl).

[1]: https://srlabs.de/badusb/
[2]: http://goodfet.sourceforge.net/hardware/facedancer11/
[3]: https://marc.info/?l=oss-security&m=140749685512320&w=2
[4]: https://marc.info/?l=oss-security&m=140751502119399&w=2
[5]: https://marc.info/?l=oss-security&m=140753051926692&w=2
[6]: https://marc.info/?l=oss-security&m=140752686125379&w=2
Comment 1 Yves-Alexis 2014-08-09 09:14:30 UTC
So, it seems that the correct way is to do:

for bus in /sys/bus/usb/usb*;
do
  echo 0 > ${bus}/authorized_default
done

to disable registration of new devices on the USB busses. The devices still get enumerated by the kernel, but they're not handled by any driver.

Same thing with 1 (or -1) will re-enable the registration.
Comment 2 Lennart Poettering 2014-08-18 20:51:49 UTC
I can see the usefulness of this, but this also sounds like security theatre. If you just implement it like this, then you add a big DoS, because people can pull your kbd and you cannot unlock your session anymore, ever. Unless of course you accept keyboards that are plugged back in. But in that case, the whole excercise is moot.

Hence I am not convinced that this is really a sound idea, I must say.
Comment 3 Tobias Mueller 2015-02-19 21:56:42 UTC
I can see benefits.  For one, a keyboard is usually a relatively dumb HID device. So not much harm caused. Especially not if you already had the very same vendorid and productid attached.  The attack surface is certainly smaller when only allowing a limited set of (already seen) devices.

Spontaneously, that would would be a great security feature for single user machines running contemporary desktops.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.