On Mon, Nov 30, 2015 at 06:12:22PM +0100, Krzysztof Opasiak wrote: > > > On 11/30/2015 05:16 PM, Alan Stern wrote: > >On Fri, 27 Nov 2015, Krzysztof Opasiak wrote: > > > >>>>I run through your code and as far as I understand above is not exactly > >>>>true. Your patch allows only to prevent userspace from accessing interfaces > >>>>which has kernel drivers, there is no way to stop an application from taking > >>>>control over all free interfaces. > >>>> > >>>>Let's say that your device has 3 interfaces. First of them has a kernel > >>>>driver but second and third doesn't. You have 2 apps. One should communicate > >>>>using second interface and another one third. But first app is malicious and > >>>>it claims all free interfaces of received device (your patch doesn't prevent > >>>>this). And when second app starts it is unable to do anything with the > >>>>device because all interfaces are taken. How would you like to handle this? > >>> > >>>You can't, and why would you ever want to, as you can't tell what an app > >>>"should" or "should not" do. If you really care about this, then use a > >>>LSM policy to prevent this. > >> > >>Well, an app can declare what it does and what it needs in it's manifest > >>file (or some equivalent of this) and the platform should ensure that > >>app can do only what it has declared. > >> > >>I would really like to use LSM policy in here but currently it is > >>impossible as one device node represents whole device. Permissions (even > >>those from LSM) are being checked only on open() not on each ioctl() so > >>as far as I know there is nothing which prevents any owner of opened fd > >>to claim all available (not taken by someone else) interfaces and LSM > >>policy is unable to filter those calls (unless we add some LSM hooks > >>over there). > > > >How about this approach? Once a process has dropped its usbfs > >privileges, it's not allowed to claim any interfaces (either explicitly > >or implicitly). Instead, it or some manager program must claim the > >appropriate interfaces before dropping privileges. > > > > I agree that restricting interface claiming only to privileged process is a > good idea. Unfortunately this generates a problem when program needs more > than one interface (like in cdc - data + control for example). We need to > declare both of them in first call to "usb-manager" or reopen the dev node > at second call and claim all interfaces claimed using this fd till now and > claim one more and then drop privileges and send a new fd. Have you seen such a device that is controlled this way in userspace? Don't over-engineer something that is probably pretty rare... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
