Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Andy Lutomirski wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. Just to make sure we are on the same page -- this is really only about setting proper device node permissions and nothing else, right? My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. You can get it from different other places though, such as libusb (but then you are limited only to USB HID devices ... which might be enough in your particular case). - A udev helper that does this and doesn't live in the systemd tree. I don't love this option -- I'd prefer for this to be as plug-and-play as possible. Agreed. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Andy Lutomirski wrote: Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. Huh? I have /sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor on my system. Brainfart on my side. We have 'rdesc' and 'events' in debugfs sice a long time, but then 'report_descriptor' has been added as a proper sysfs attribute some time around 3.0. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. I'm not sure that U2F counts as a very good reason. It might well be the justifying reason. I'd first like to see what other options we have though. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. The HID group part is trivial, but what interface would the driver expose? I don't think that a udev rule for hidraw matching the modalias makes any sense, and, if it were a real driver, what interface would it expose? Most cross-platform userspace code for U2F is likely to use HIDAPI. Admittedly, a U2F driver in the kernel would be slightly nicer from a multiplexing standpoint than hidraw. Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
