* HID vendor access from user space @ 2013-05-17 11:47 Nestor Lopez Casado 2013-05-21 13:12 ` David Herrmann 0 siblings, 1 reply; 15+ messages in thread From: Nestor Lopez Casado @ 2013-05-17 11:47 UTC (permalink / raw) To: Jiri Kosina, Dmitry Torokhov, Benjamin Tissoires, Andrew de los Reyes, David Herrmann, open list:HID CORE LAYER, Olivier Gay Hi, In today's linux HID subsystem, a HID device can be accessed for control and configuration via dev/hidraw, via a hid-specific driver, as well as /dev/input (setting leds on a kbd for instance) Some HID devices share multiple functionality in the same HID interface, think of a keyboard with a touchpad and a vendor specific collection for configuration, special status, etc. For such device, there will be one hidraw node, and hid-input will take care of parsing the keyboard/mouse collections into the proper input objects. The vendor collection will be ignored. If a user wants to configure/control the device there are two choices, either write a hid-specific driver to deal with the vendor specific collection, or open the corresponding /hidraw node from userspace. But a hidraw node that carries system input data requires root priviledges. I'm interested in hearing your opinions on how to add the capability for a normal user process to control/configure a HID device via reports exchanged with a vendor collection. I have one proposal, which is to create, say "/dev/hidvendorX", nodes for all top level HID collections which are today ignored by hid-input and/or other subsystems. These nodes would not require root priviledge by default and thus, users could control/reconfigure their devices from a standard application while keeping the "standard" input functionality intact. Cheers, Nestor ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2013-05-17 11:47 HID vendor access from user space Nestor Lopez Casado @ 2013-05-21 13:12 ` David Herrmann 2014-04-02 7:05 ` Nestor Lopez Casado 0 siblings, 1 reply; 15+ messages in thread From: David Herrmann @ 2013-05-21 13:12 UTC (permalink / raw) To: Nestor Lopez Casado Cc: Jiri Kosina, Dmitry Torokhov, Benjamin Tissoires, Andrew de los Reyes, open list:HID CORE LAYER, Olivier Gay Hi On Fri, May 17, 2013 at 1:47 PM, Nestor Lopez Casado <nlopezcasad@logitech.com> wrote: > Hi, > > In today's linux HID subsystem, a HID device can be accessed for > control and configuration via dev/hidraw, via a hid-specific driver, > as well as /dev/input (setting leds on a kbd for instance) > > Some HID devices share multiple functionality in the same HID > interface, think of a keyboard with a touchpad and a vendor specific > collection for configuration, special status, etc. > > For such device, there will be one hidraw node, and hid-input will > take care of parsing the keyboard/mouse collections into the proper > input objects. > > The vendor collection will be ignored. > > If a user wants to configure/control the device there are two choices, > either write a hid-specific driver to deal with the vendor specific > collection, or open the corresponding /hidraw node from userspace. > > But a hidraw node that carries system input data requires root priviledges. > > I'm interested in hearing your opinions on how to add the capability > for a normal user process to control/configure a HID device via > reports exchanged with a vendor collection. > > I have one proposal, which is to create, say "/dev/hidvendorX", nodes > for all top level HID collections which are today ignored by hid-input > and/or other subsystems. > > These nodes would not require root priviledge by default and thus, > users could control/reconfigure their devices from a standard > application while keeping the "standard" input functionality intact. Why not write a kernel driver? We have a pretty nice infrastructure for all this. If it's a license-issue, I recommend using udev rules to change permissions on the requested devices directly during setup. You can then use hidraw. It would also help if you could describe the driver design. Do you run it as daemon and feed data back into the kernel? Or do you forward it to the xserver? Or what kind of setup do you have? For instance, a library design would require dynamic permission setup, while a daemon-design would allow static file-system permissions. Furthermore, is it still an input driver? Or do you tunnel non-input data via HID? Regards David ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2013-05-21 13:12 ` David Herrmann @ 2014-04-02 7:05 ` Nestor Lopez Casado 2014-04-03 13:57 ` Jiri Kosina 0 siblings, 1 reply; 15+ messages in thread From: Nestor Lopez Casado @ 2014-04-02 7:05 UTC (permalink / raw) To: David Herrmann Cc: Jiri Kosina, Dmitry Torokhov, Andrew de los Reyes, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires Hi, let me resuscitate this thread as we will have some resources to work on this within a few weeks. I suggest re-reading the previous emails to refresh the context of this discussion. On Tue, May 21, 2013 at 3:12 PM, David Herrmann <dh.herrmann@gmail.com> wrote: > Hi > > On Fri, May 17, 2013 at 1:47 PM, Nestor Lopez Casado > <nlopezcasad@logitech.com> wrote: >> Hi, >> >> In today's linux HID subsystem, a HID device can be accessed for >> control and configuration via dev/hidraw, via a hid-specific driver, >> as well as /dev/input (setting leds on a kbd for instance) >> >> Some HID devices share multiple functionality in the same HID >> interface, think of a keyboard with a touchpad and a vendor specific >> collection for configuration, special status, etc. >> >> For such device, there will be one hidraw node, and hid-input will >> take care of parsing the keyboard/mouse collections into the proper >> input objects. >> >> The vendor collection will be ignored. >> >> If a user wants to configure/control the device there are two choices, >> either write a hid-specific driver to deal with the vendor specific >> collection, or open the corresponding /hidraw node from userspace. >> >> But a hidraw node that carries system input data requires root priviledges. >> >> I'm interested in hearing your opinions on how to add the capability >> for a normal user process to control/configure a HID device via >> reports exchanged with a vendor collection. >> >> I have one proposal, which is to create, say "/dev/hidvendorX", nodes >> for all top level HID collections which are today ignored by hid-input >> and/or other subsystems. >> >> These nodes would not require root priviledge by default and thus, >> users could control/reconfigure their devices from a standard >> application while keeping the "standard" input functionality intact. > > Why not write a kernel driver? We have a pretty nice infrastructure > for all this. Do you mean a "hid-specific" driver for certain vid & pid devices ? > > If it's a license-issue, I recommend using udev rules to change > permissions on the requested devices directly during setup. You can > then use hidraw. It is not a license issue, it is a security issue. Every hid class interface, (either usb, bluetooth, i2c, etc) has an associated hidraw node, and that node aggregates all reports sent from the device. Say that for example, the device has a keyboard collection and a vendor collection, then changing permissions on the associated hidraw node (so as to give any desktop user unrestricted access to the vendor collection) would open the door to malicious code that could log the keyboard activity (as both the vendor reports and input reports are seen on the same hidraw node) What we really want, is that vendor reports which come from hid vendor collections not claimed by hid-input, are made available in separate device nodes. > It would also help if you could describe the driver design. Do you run > it as daemon and feed data back into the kernel? Or do you forward it > to the xserver? Or what kind of setup do you have? For instance, a > library design would require dynamic permission setup, while a > daemon-design would allow static file-system permissions. > Furthermore, is it still an input driver? Or do you tunnel non-input > data via HID? I see this proposal as an extension to hidraw.c. The functionality offered would be similar to that proposed by hidraw, but instead of providing access to all device reports, only those tagged as being "vendor usage" would be exposed. Let's take a concrete device example based on the following hid interface descriptor: 0x05 , 0x01, // USAGE_PAGE (Generic Desktop) 0x09 , 0x06, // USAGE (Keyboard) 0xA1 , 0x01, // COLLECTION (Application) 0x85 , 0x01, // REPORT_ID (1) 0x75 , 0x01, // REPORT_SIZE (1) 0x95 , 0x08, // REPORT_COUNT (8) 0x05 , 0x07, // USAGE_PAGE (Keyboard) [snip] 0x19 , 0x00, // USAGE_MINIMUM (Reserved (no event indicated)) 0x29 , 0xFF, // USAGE_MAXIMUM (Reserved (no event indicated)) 0x81 , 0x00, // INPUT (Data,Ary,Abs) 0xC0, // END_COLLECTION 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined Page 1) 0x09, 0x02, // Usage (Vendor Usage 2) 0xA1, 0x01, // Collection (Application) 0x85, 0x11, // REPORT_ID (17) 0x75, 0x08, // REPORT_SIZE (8) 0x95, 0x13, // REPORT_COUNT (19) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xFF, 0x00, // LOGICAL_MAXIMUM (255) 0x09, 0x02, // USAGE (Vendor Usage 2) 0x81, 0x00, // INPUT (data,Ary,Abs) 0x09, 0x02, // USAGE (Vendor Usage 2) 0x91, 0x00, // OUTPUT (data,Ary,Abs) 0xC0, // End Collection In today's context, this would create one device node: /dev/hidrawX After the proposal has been implemented, it would create: /dev/hidrawX (access to the full hid interface including reports IDs 1 and 17, no change compared to today) /dev/hidvendorX (access to reportID 17 only) Full user rights can be granted to all desktop users for /dev/hidvendorX while keeping the input reports (report ID 1) secure. > > Regards > David > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, -nestor ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-02 7:05 ` Nestor Lopez Casado @ 2014-04-03 13:57 ` Jiri Kosina 2014-04-07 16:15 ` Nestor Lopez Casado 0 siblings, 1 reply; 15+ messages in thread From: Jiri Kosina @ 2014-04-03 13:57 UTC (permalink / raw) To: Nestor Lopez Casado Cc: David Herrmann, Dmitry Torokhov, Andrew de los Reyes, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires On Wed, 2 Apr 2014, Nestor Lopez Casado wrote: > >> If a user wants to configure/control the device there are two choices, > >> either write a hid-specific driver to deal with the vendor specific > >> collection, or open the corresponding /hidraw node from userspace. > >> > >> But a hidraw node that carries system input data requires root priviledges. > >> > >> I'm interested in hearing your opinions on how to add the capability > >> for a normal user process to control/configure a HID device via > >> reports exchanged with a vendor collection. > >> > >> I have one proposal, which is to create, say "/dev/hidvendorX", nodes > >> for all top level HID collections which are today ignored by hid-input > >> and/or other subsystems. > >> > >> These nodes would not require root priviledge by default and thus, > >> users could control/reconfigure their devices from a standard > >> application while keeping the "standard" input functionality intact. > > > > Why not write a kernel driver? We have a pretty nice infrastructure > > for all this. > > Do you mean a "hid-specific" driver for certain vid & pid devices ? I indeed believe that it's what David was proposing. Writing in-kernel drivers that handle just specific collections/usages, and let the rest be handled by the core infrastructure, is super-easy these days. Also, if you need users to be able to trigger particular actions being perfomed by the driver, sysfs knobs should be a reasonable way to doing this. As an example of such interface -- creating a sysfs trigger for hid-logitech-dj that will send the pairing command to the unified receiver, has been on my TODO list for quite some time already (and was even suggested by Linus). > > If it's a license-issue, I recommend using udev rules to change > > permissions on the requested devices directly during setup. You can > > then use hidraw. > It is not a license issue, it is a security issue. > > Every hid class interface, (either usb, bluetooth, i2c, etc) has an > associated hidraw node, and that node aggregates all reports sent from > the device. > > Say that for example, the device has a keyboard collection and a > vendor collection, then changing permissions on the associated hidraw > node (so as to give any desktop user unrestricted access to the vendor > collection) would open the door to malicious code that could log the > keyboard activity (as both the vendor reports and input reports are > seen on the same hidraw node) I think I am missing the point here. If you own the credentials of the session owner, you can log keystrokes anyway even now, just use xinput list xinput test <id> and see the result :) Admittedly, this is a little bit more difficult when you are outside X11 session, but I am not sure how much concerned you are about such scenario anyway. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-03 13:57 ` Jiri Kosina @ 2014-04-07 16:15 ` Nestor Lopez Casado 2014-04-07 16:27 ` David Herrmann 0 siblings, 1 reply; 15+ messages in thread From: Nestor Lopez Casado @ 2014-04-07 16:15 UTC (permalink / raw) To: Jiri Kosina Cc: David Herrmann, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser On Thu, Apr 3, 2014 at 3:57 PM, Jiri Kosina <jkosina@suse.cz> wrote: > On Wed, 2 Apr 2014, Nestor Lopez Casado wrote: > >> >> If a user wants to configure/control the device there are two choices, >> >> either write a hid-specific driver to deal with the vendor specific >> >> collection, or open the corresponding /hidraw node from userspace. >> >> >> >> But a hidraw node that carries system input data requires root priviledges. >> >> >> >> I'm interested in hearing your opinions on how to add the capability >> >> for a normal user process to control/configure a HID device via >> >> reports exchanged with a vendor collection. >> >> >> >> I have one proposal, which is to create, say "/dev/hidvendorX", nodes >> >> for all top level HID collections which are today ignored by hid-input >> >> and/or other subsystems. >> >> >> >> These nodes would not require root priviledge by default and thus, >> >> users could control/reconfigure their devices from a standard >> >> application while keeping the "standard" input functionality intact. >> > >> > Why not write a kernel driver? We have a pretty nice infrastructure >> > for all this. >> >> Do you mean a "hid-specific" driver for certain vid & pid devices ? > > I indeed believe that it's what David was proposing. Writing in-kernel > drivers that handle just specific collections/usages, and let the rest > be handled by the core infrastructure, is super-easy these days. I don't think that the burden of hid input device status and configuration should belong to the kernel 'for all devices in all situations', as it would mandate the proliferation of many hid specific code and too much kernel bloating that would be best handled at a higher level. If we take for example the Logitech devices, we have many features which are accessible via vendor collections, and the easiest way to use them is via a user space application or library. > > Also, if you need users to be able to trigger particular actions being > perfomed by the driver, sysfs knobs should be a reasonable way to doing > this. > > As an example of such interface -- creating a sysfs trigger for > hid-logitech-dj that will send the pairing command to the unified > receiver, has been on my TODO list for quite some time already (and was > even suggested by Linus). > This is fine, but this solves a very particular case, the pairing/unpairing of devices with the Unifying receiver. There is much more to device configuration that just pairing/unpairing, it does not even need to be Unifying devices, or Logitech devices, for that matter. (See also previous comment) >> > If it's a license-issue, I recommend using udev rules to change >> > permissions on the requested devices directly during setup. You can >> > then use hidraw. >> It is not a license issue, it is a security issue. >> >> Every hid class interface, (either usb, bluetooth, i2c, etc) has an >> associated hidraw node, and that node aggregates all reports sent from >> the device. >> >> Say that for example, the device has a keyboard collection and a >> vendor collection, then changing permissions on the associated hidraw >> node (so as to give any desktop user unrestricted access to the vendor >> collection) would open the door to malicious code that could log the >> keyboard activity (as both the vendor reports and input reports are >> seen on the same hidraw node) > > I think I am missing the point here. If you own the credentials of the > session owner, you can log keystrokes anyway even now, just use > > xinput list > xinput test <id> > > and see the result :) Admittedly, this is a little bit more difficult when > you are outside X11 session, but I am not sure how much concerned you are > about such scenario anyway. Oh, this I did not know! Let me try to sketch the scenario we are concerned with: We want user processes to be able to communicate with hid input devices, via vendor specific commands. This vendor specific data flows thru hid vendor reports. Today, user processes can only access these reports via hidraw. Hidraw aggregates user input (keyboard, mouse, etc) with vendor reports. Hidraw nodes are owned by root by default. This means that an unprivileged user would not be able to send vendor commands to a hid device. On the other hand, if an unprivileged user (or group) is given access to hidraw, then she will also be able to spy the input, even if she is remotely logged to a computer. We consider this a potential security problem and we are looking into a solution that would enable the currently logged local user to access the vendor collections of a hid device without requiring any special permissions. Maybe the solution is not within the kernel itself, but rather on using a user mode component, maybe the X server or even udev. Do you get my point now ? > > -- > Jiri Kosina > SUSE Labs -nestor. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-07 16:15 ` Nestor Lopez Casado @ 2014-04-07 16:27 ` David Herrmann 2014-04-08 15:53 ` Nestor Lopez Casado 0 siblings, 1 reply; 15+ messages in thread From: David Herrmann @ 2014-04-07 16:27 UTC (permalink / raw) To: Nestor Lopez Casado Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser Hi On Mon, Apr 7, 2014 at 6:15 PM, Nestor Lopez Casado <nlopezcasad@logitech.com> wrote: > We consider this a potential security problem and we are looking into > a solution that would enable the currently logged local user to access > the vendor collections of a hid device without requiring any special > permissions. > > Maybe the solution is not within the kernel itself, but rather on > using a user mode component, maybe the X server or even udev. Do you > get my point now ? There is a lot of work going on to make Xorg (and also Wayland compositors) run as non-root. Many people, however, seem to ignore that this means the compositor runs with the _same_ privileges as the applications. At least that is the security model we are going for. Therefore, if a compositor can access input devices, all applications can do so, too. Of course, you can introduce new privilege-levels and or run applications with less privileges than normal user processes. But I guess you get the point. Therefore, I really doubt there is much need to split the access-rights here. What you wanna do is to provide this privilege-separation on the kernel level. However, I think this is the wrong way to do it. Imagine an HID device that has several vendor-commands, some of them rather trivial and un-privileged, others not. Do you expect the kernel to provide one device-node for each? How do you expect the kernel to know which vender-extensions are _safe_ to be grouped together? Yes, the kernel should provide different interfaces for different hw-features so user-space can apply fine-grained access-modes. However, if we don't know what hardware feature a specific command represents, I don't think we should apply some kind of random interface separation. This is why Jiri and I recommend writing an in-kernel driver. That driver can be small and all it does it provide a separate interface for your vendor-extensions. This can be as easy as setting HID_QUIRK_MULTI_INPUT for given devices (or an equivalent HID_QUIRK_MULTI_HIDRAW, which doesn't exist, yet). I still think it would be nicer if the kernel provides a proper interface-abstraction, but I'd be fine with such a quirk, too. Maybe you can describe one specific example? Otherwise, it's hard to imagine hid devices that provide two totally separate interfaces that we had the need to split them. All examples I know already provide different virtual HID devices and thus don't suffer from this problem. Furthermore, did you do some research how other platforms deal with it? Thanks David ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-07 16:27 ` David Herrmann @ 2014-04-08 15:53 ` Nestor Lopez Casado 2014-04-14 10:00 ` Nestor Lopez Casado 0 siblings, 1 reply; 15+ messages in thread From: Nestor Lopez Casado @ 2014-04-08 15:53 UTC (permalink / raw) To: David Herrmann Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser On Mon, Apr 7, 2014 at 6:27 PM, David Herrmann <dh.herrmann@gmail.com> wrote: > Hi > > On Mon, Apr 7, 2014 at 6:15 PM, Nestor Lopez Casado > <nlopezcasad@logitech.com> wrote: >> We consider this a potential security problem and we are looking into >> a solution that would enable the currently logged local user to access >> the vendor collections of a hid device without requiring any special >> permissions. >> >> Maybe the solution is not within the kernel itself, but rather on >> using a user mode component, maybe the X server or even udev. Do you >> get my point now ? > > There is a lot of work going on to make Xorg (and also Wayland > compositors) run as non-root. Many people, however, seem to ignore > that this means the compositor runs with the _same_ privileges as the > applications. At least that is the security model we are going for. > Therefore, if a compositor can access input devices, all applications > can do so, too. Of course, you can introduce new privilege-levels and > or run applications with less privileges than normal user processes. > But I guess you get the point. > > Therefore, I really doubt there is much need to split the > access-rights here. What you wanna do is to provide this > privilege-separation on the kernel level. However, I think this is the > wrong way to do it. Imagine an HID device that has several > vendor-commands, some of them rather trivial and un-privileged, others > not. Do you expect the kernel to provide one device-node for each? How > do you expect the kernel to know which vender-extensions are _safe_ to > be grouped together? I do not expect the kernel to know whether vendor extensions are safe to be grouped together, I would simply provide them as a separate -user accessible- interface whose access rights can be assigned separately from the classic input collections. Assignment of access rights would then be up to udev rules. Which each manufacturer/user can define for each of its devices. By default access rights would stay for root only. > > Yes, the kernel should provide different interfaces for different > hw-features so user-space can apply fine-grained access-modes. > However, if we don't know what hardware feature a specific command > represents, I don't think we should apply some kind of random > interface separation. This is why Jiri and I recommend writing an > in-kernel driver. That driver can be small and all it does it provide > a separate interface for your vendor-extensions. This can be as easy > as setting HID_QUIRK_MULTI_INPUT for given devices (or an equivalent > HID_QUIRK_MULTI_HIDRAW, which doesn't exist, yet). I still think it > would be nicer if the kernel provides a proper interface-abstraction, > but I'd be fine with such a quirk, too. The problem I see with a specific kernel driver for a specific vendor extension is two fold: 1) It creates some potential for code bloat/duplication in the kernel across multiple drivers for different manufacturers, while the only purpose of this driver would be to expose some raw vendor functionality to user programs. 2) The interface provided by this driver to user programs would probably diverge from driver to driver, making it impossible to have a generic user component (think signal11's HidApi lib for instance) to provide a consistent hid access library across operating systems. > > Maybe you can describe one specific example? Otherwise, it's hard to > imagine hid devices that provide two totally separate interfaces that > we had the need to split them. All examples I know already provide > different virtual HID devices and thus don't suffer from this problem. You can look at the hid device descriptor that I posted in a previous message of this thread. This device descriptor actually comes from one of our devices: The Logitech BT Illuminated kbd K810. Most of our input devices follow this pattern: - Top level "classic" collection types (mouse, keyboard, etc) - Top level vendor collections. The vendor collections are the method we use to access extended functionality of the device, (button reprogrammability, dpi settings, extended battery status, firmware update and many others) > Furthermore, did you do some research how other platforms deal with > it? Neither Microsoft Windows nor Apple Mac OS provide a posix-style filesystem based device access model for HID devices. Nevertheless, Windows does provide "physical device objects" for each top level collection found in a hid device. From msdn: "A report descriptor can include more than one top-level collection. The HID class driver enumerates the top-level collections of an input device and creates a physical device object (PDO) for each top-level collection. User-mode applications or kernel-mode drivers can access a top-level collection by opening its PDO and using the HIDClass support routines and the HID class driver IOCTLs" Access rights to vendor collection PDOs is granted to any logged on user. Apple's Mac OS HidManager client API, provides a mechanism to select the parent device of any top level hid collection, then Set/Get report-style APIs to address each of the vendor collections. Access rights seem to be given to any logged on user. > > Thanks > David ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-08 15:53 ` Nestor Lopez Casado @ 2014-04-14 10:00 ` Nestor Lopez Casado 2014-04-15 2:16 ` David Herrmann 2014-04-15 7:39 ` Jiri Kosina 0 siblings, 2 replies; 15+ messages in thread From: Nestor Lopez Casado @ 2014-04-14 10:00 UTC (permalink / raw) To: David Herrmann Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser David, Jiri, After considering our discussion here, which is your position on extending the hidraw nodes to include separate nodes for top level vendor collections ? Cheers, -nestor On Tue, Apr 8, 2014 at 5:53 PM, Nestor Lopez Casado <nlopezcasad@logitech.com> wrote: > On Mon, Apr 7, 2014 at 6:27 PM, David Herrmann <dh.herrmann@gmail.com> wrote: >> Hi >> >> On Mon, Apr 7, 2014 at 6:15 PM, Nestor Lopez Casado >> <nlopezcasad@logitech.com> wrote: >>> We consider this a potential security problem and we are looking into >>> a solution that would enable the currently logged local user to access >>> the vendor collections of a hid device without requiring any special >>> permissions. >>> >>> Maybe the solution is not within the kernel itself, but rather on >>> using a user mode component, maybe the X server or even udev. Do you >>> get my point now ? >> >> There is a lot of work going on to make Xorg (and also Wayland >> compositors) run as non-root. Many people, however, seem to ignore >> that this means the compositor runs with the _same_ privileges as the >> applications. At least that is the security model we are going for. >> Therefore, if a compositor can access input devices, all applications >> can do so, too. Of course, you can introduce new privilege-levels and >> or run applications with less privileges than normal user processes. >> But I guess you get the point. >> >> Therefore, I really doubt there is much need to split the >> access-rights here. What you wanna do is to provide this >> privilege-separation on the kernel level. However, I think this is the >> wrong way to do it. Imagine an HID device that has several >> vendor-commands, some of them rather trivial and un-privileged, others >> not. Do you expect the kernel to provide one device-node for each? How >> do you expect the kernel to know which vender-extensions are _safe_ to >> be grouped together? > > I do not expect the kernel to know whether vendor extensions are safe > to be grouped together, I would simply provide them as a separate > -user accessible- interface whose access rights can be assigned > separately from the classic input collections. > > Assignment of access rights would then be up to udev rules. Which each > manufacturer/user can define for each of its devices. By default > access rights would stay for root only. > >> >> Yes, the kernel should provide different interfaces for different >> hw-features so user-space can apply fine-grained access-modes. >> However, if we don't know what hardware feature a specific command >> represents, I don't think we should apply some kind of random >> interface separation. This is why Jiri and I recommend writing an >> in-kernel driver. That driver can be small and all it does it provide >> a separate interface for your vendor-extensions. This can be as easy >> as setting HID_QUIRK_MULTI_INPUT for given devices (or an equivalent >> HID_QUIRK_MULTI_HIDRAW, which doesn't exist, yet). I still think it >> would be nicer if the kernel provides a proper interface-abstraction, >> but I'd be fine with such a quirk, too. > > The problem I see with a specific kernel driver for a specific vendor > extension is two fold: > 1) It creates some potential for code bloat/duplication in the kernel > across multiple drivers for different manufacturers, while the only > purpose of this driver would be to expose some raw vendor > functionality to user programs. > > 2) The interface provided by this driver to user programs would > probably diverge from driver to driver, making it impossible to have a > generic user component (think signal11's HidApi lib for instance) to > provide a consistent hid access library across operating systems. > >> >> Maybe you can describe one specific example? Otherwise, it's hard to >> imagine hid devices that provide two totally separate interfaces that >> we had the need to split them. All examples I know already provide >> different virtual HID devices and thus don't suffer from this problem. > > You can look at the hid device descriptor that I posted in a previous > message of this thread. This device descriptor actually comes from one > of our devices: The Logitech BT Illuminated kbd K810. Most of our > input devices follow this pattern: > > - Top level "classic" collection types (mouse, keyboard, etc) > - Top level vendor collections. > > The vendor collections are the method we use to access extended > functionality of the device, (button reprogrammability, dpi settings, > extended battery status, firmware update and many others) > >> Furthermore, did you do some research how other platforms deal with >> it? > > Neither Microsoft Windows nor Apple Mac OS provide a posix-style > filesystem based device access model for HID devices. Nevertheless, > Windows does provide "physical device objects" for each top level > collection found in a hid device. From msdn: > > "A report descriptor can include more than one top-level collection. > The HID class driver enumerates the top-level collections of an input > device and creates a physical device object (PDO) for each top-level > collection. User-mode applications or kernel-mode drivers can access a > top-level collection by opening its PDO and using the HIDClass support > routines and the HID class driver IOCTLs" > > Access rights to vendor collection PDOs is granted to any logged on user. > > Apple's Mac OS HidManager client API, provides a mechanism to select > the parent device of any top level hid collection, then Set/Get > report-style APIs to address each of the vendor collections. > > Access rights seem to be given to any logged on user. > >> >> Thanks >> David ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-14 10:00 ` Nestor Lopez Casado @ 2014-04-15 2:16 ` David Herrmann 2014-04-15 7:36 ` Nestor Lopez Casado 2014-04-15 7:39 ` Jiri Kosina 1 sibling, 1 reply; 15+ messages in thread From: David Herrmann @ 2014-04-15 2:16 UTC (permalink / raw) To: Nestor Lopez Casado Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser Hi On Mon, Apr 14, 2014 at 12:00 PM, Nestor Lopez Casado <nlopezcasad@logitech.com> wrote: > David, Jiri, > > After considering our discussion here, which is your position on > extending the hidraw nodes to include separate nodes for top level > vendor collections ? Patches, patches, patches! I am currently on the road, but it's always easier to see real code than just the theory. I have no real objections to provide multiple hidraw interfaces. However, I think that doesn't solve your problem. For instance, you still need to set proper access-rights on the hidraw node. However, some other devices might export unsafe interfaces via vendor-extensions, and you don't wanna make those hidraw nodes user-accessible. Therefore, you still need a udev-rule to match on Logitech-stuff. You could do that as a small Logitech-driver in the kernel. But ok, I'm fine with moving those whitelists to user-space. Thanks David ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-15 2:16 ` David Herrmann @ 2014-04-15 7:36 ` Nestor Lopez Casado 0 siblings, 0 replies; 15+ messages in thread From: Nestor Lopez Casado @ 2014-04-15 7:36 UTC (permalink / raw) To: David Herrmann Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser Ok, thanks David. -nestor On Tue, Apr 15, 2014 at 4:16 AM, David Herrmann <dh.herrmann@gmail.com> wrote: > Hi > > On Mon, Apr 14, 2014 at 12:00 PM, Nestor Lopez Casado > <nlopezcasad@logitech.com> wrote: >> David, Jiri, >> >> After considering our discussion here, which is your position on >> extending the hidraw nodes to include separate nodes for top level >> vendor collections ? > > Patches, patches, patches! > > I am currently on the road, but it's always easier to see real code > than just the theory. I have no real objections to provide multiple > hidraw interfaces. However, I think that doesn't solve your problem. > For instance, you still need to set proper access-rights on the hidraw > node. However, some other devices might export unsafe interfaces via > vendor-extensions, and you don't wanna make those hidraw nodes > user-accessible. Therefore, you still need a udev-rule to match on > Logitech-stuff. You could do that as a small Logitech-driver in the > kernel. But ok, I'm fine with moving those whitelists to user-space. > > Thanks > David ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-14 10:00 ` Nestor Lopez Casado 2014-04-15 2:16 ` David Herrmann @ 2014-04-15 7:39 ` Jiri Kosina 2014-04-15 8:47 ` Nestor Lopez Casado 1 sibling, 1 reply; 15+ messages in thread From: Jiri Kosina @ 2014-04-15 7:39 UTC (permalink / raw) To: Nestor Lopez Casado Cc: David Herrmann, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser On Mon, 14 Apr 2014, Nestor Lopez Casado wrote: > After considering our discussion here, which is your position on > extending the hidraw nodes to include separate nodes for top level > vendor collections ? The exact usecase is still a bit unclear to me. Has there been any explanation how you are going to deal with the fact that X protocol exposes all the events to X session owner anyway? (sorry if it was and I missed it). Frankly, I'd really like to avoid any parsing (deciding about collections) whatsoever around hidraw, as that was the whole point of creating it in parallel to hiddev was simply 'no parsing, raw access'. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-15 7:39 ` Jiri Kosina @ 2014-04-15 8:47 ` Nestor Lopez Casado 2014-04-16 14:53 ` Jiri Kosina 0 siblings, 1 reply; 15+ messages in thread From: Nestor Lopez Casado @ 2014-04-15 8:47 UTC (permalink / raw) To: Jiri Kosina Cc: David Herrmann, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser On Tue, Apr 15, 2014 at 9:39 AM, Jiri Kosina <jkosina@suse.cz> wrote: > On Mon, 14 Apr 2014, Nestor Lopez Casado wrote: > >> After considering our discussion here, which is your position on >> extending the hidraw nodes to include separate nodes for top level >> vendor collections ? > > The exact usecase is still a bit unclear to me. Has there been any > explanation how you are going to deal with the fact that X protocol > exposes all the events to X session owner anyway? (sorry if it was and I > missed it). The X session owner can spy its own keystrokes. This seems acceptable. Hidraw nodes are the only way a user can talk "vendor hid" with plugged devices. Once you are less restrictive with hidraw nodes (i.e. grant access to more users that root) to allow hid vendor interaction, then any of those users can log anything happening on the concerned hidraw node, even remotely. This is not the case in X. Having more granularity at the hidraw level enables assigning different user rights to the different nodes belonging to the same parent hid device, so that sensitive user input can remain protected while access to the vendor interface can be left open. As David said, this clearly does not solve "all problems", as some vendor features in some devices might not be safe to be exposed, but then it will be up to the users/vendors to grant/block access to those collections via udev rules. Moreover, this feature will keep a very similar interface to current hidraw ioctl/open/close and the code will most likely remained contained to a single module or even can simply become part of hidraw.c As David mentions, the same kind of functionality could also be achieved via hid specific drivers for vendor collections in each of the products, but it has the drawback that we will be proliferating more hid-specific drivers whose only purpose will be to expose a vendor interface to user applications, creating the potential for kernel code duplication and disparate user interfaces. > > Frankly, I'd really like to avoid any parsing (deciding about collections) > whatsoever around hidraw, as that was the whole point of creating it in > parallel to hiddev was simply 'no parsing, raw access'. We should avoid naming the new nodes "hidrawX" they could be "hidvendorX" for instance, or it could also be "hidcolX" where col stands for collection. We will be moving the "raw" one level down. It can be thought of as a multiple interface usb device that already creates multiple hidraw devices, but taken one step further. > > Thanks, > > -- > Jiri Kosina > SUSE Labs Cheers, -nestor ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-15 8:47 ` Nestor Lopez Casado @ 2014-04-16 14:53 ` Jiri Kosina 2014-04-23 9:14 ` Nestor Lopez Casado 0 siblings, 1 reply; 15+ messages in thread From: Jiri Kosina @ 2014-04-16 14:53 UTC (permalink / raw) To: Nestor Lopez Casado Cc: David Herrmann, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser On Tue, 15 Apr 2014, Nestor Lopez Casado wrote: > > Frankly, I'd really like to avoid any parsing (deciding about collections) > > whatsoever around hidraw, as that was the whole point of creating it in > > parallel to hiddev was simply 'no parsing, raw access'. > > We should avoid naming the new nodes "hidrawX" they could be > "hidvendorX" for instance, or it could also be "hidcolX" where col > stands for collection. We will be moving the "raw" one level down. I am still having trouble seeing how this would work together with current hidraw. In your proposal, there will be both hidrawX and hidcolX existing in parallel, right? Who will be deciding what goes to hidcolX instead of hidrawX? One of the pain points would be -- /dev/hidrawX will have to stay anyway for compatibility reasons, so we can't just divide it to multiple /dev/hidcolX all of a sudden and never look back. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-16 14:53 ` Jiri Kosina @ 2014-04-23 9:14 ` Nestor Lopez Casado 2014-04-23 9:27 ` David Herrmann 0 siblings, 1 reply; 15+ messages in thread From: Nestor Lopez Casado @ 2014-04-23 9:14 UTC (permalink / raw) To: Jiri Kosina Cc: David Herrmann, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser On Wed, Apr 16, 2014 at 4:53 PM, Jiri Kosina <jkosina@suse.cz> wrote: > On Tue, 15 Apr 2014, Nestor Lopez Casado wrote: > >> > Frankly, I'd really like to avoid any parsing (deciding about collections) >> > whatsoever around hidraw, as that was the whole point of creating it in >> > parallel to hiddev was simply 'no parsing, raw access'. >> >> We should avoid naming the new nodes "hidrawX" they could be >> "hidvendorX" for instance, or it could also be "hidcolX" where col >> stands for collection. We will be moving the "raw" one level down. > > I am still having trouble seeing how this would work together with current > hidraw. > > In your proposal, there will be both hidrawX and hidcolX existing in > parallel, right? Yes. > Who will be deciding what goes to hidcolX instead of > hidrawX? The additional code that we will put in place. Having said that, hidrawX will still get the same reports as before, nothing will change for those nodes. > One of the pain points would be -- /dev/hidrawX will have to stay > anyway for compatibility reasons, so we can't just divide it to multiple > /dev/hidcolX all of a sudden and never look back. That's true. A device with one mouse collection and one vendor collection would give something like this: /dev/input/eventX (no change) this comes via hid-input /dev/mouse (no change) /dev/hidrawX (no change) (all reports still show up here) /dev/hidcolX (reports from corresponding colX will show up here) So only top level vendor collections which are not parsed (claimed) by any hid-xx module today would appear under hidcolX. Unless you have a major blocker, as David said, I think the best would be to come up with some code and post a proposal patch for consideration. > > -- > Jiri Kosina > SUSE Labs Cheers, -nestor ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: HID vendor access from user space 2014-04-23 9:14 ` Nestor Lopez Casado @ 2014-04-23 9:27 ` David Herrmann 0 siblings, 0 replies; 15+ messages in thread From: David Herrmann @ 2014-04-23 9:27 UTC (permalink / raw) To: Nestor Lopez Casado Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, Olivier Gay, Benjamin Tissoires, Mathieu Meisser Hi On Wed, Apr 23, 2014 at 11:14 AM, Nestor Lopez Casado <nlopezcasad@logitech.com> wrote: > A device with one mouse collection and one vendor collection would > give something like this: > /dev/input/eventX (no change) this comes via hid-input > /dev/mouse (no change) > /dev/hidrawX (no change) (all reports still show up here) > /dev/hidcolX (reports from corresponding colX will show up here) > > So only top level vendor collections which are not parsed (claimed) by > any hid-xx module today would appear under hidcolX. I still think you should do that in user-space. That is, whatever daemon opens the input-device should provide this abstraction (like via XInput2 etc.). Otherwise, someone else pops up and tells us a specific non-vendor extension is also unprivileged and wants them as separate interface. There is no clear split how fine-grained the access-control should be. Yes, you might have a specific example, but we don't want to make that a generic interface. Thanks David ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-04-23 9:27 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-17 11:47 HID vendor access from user space Nestor Lopez Casado 2013-05-21 13:12 ` David Herrmann 2014-04-02 7:05 ` Nestor Lopez Casado 2014-04-03 13:57 ` Jiri Kosina 2014-04-07 16:15 ` Nestor Lopez Casado 2014-04-07 16:27 ` David Herrmann 2014-04-08 15:53 ` Nestor Lopez Casado 2014-04-14 10:00 ` Nestor Lopez Casado 2014-04-15 2:16 ` David Herrmann 2014-04-15 7:36 ` Nestor Lopez Casado 2014-04-15 7:39 ` Jiri Kosina 2014-04-15 8:47 ` Nestor Lopez Casado 2014-04-16 14:53 ` Jiri Kosina 2014-04-23 9:14 ` Nestor Lopez Casado 2014-04-23 9:27 ` David Herrmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.