On Mon, Apr 7, 2014 at 6:27 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > Hi > > On Mon, Apr 7, 2014 at 6:15 PM, Nestor Lopez Casado > <nlopezcasad@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
