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? 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 -- 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
