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. Alan Stern -- 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
