From mboxrd@z Thu Jan 1 00:00:00 1970 From: Krzysztof Opasiak Subject: Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Date: Mon, 30 Nov 2015 19:48:56 +0100 Message-ID: <565C9A18.6000006@samsung.com> References: <565C8376.6070505@samsung.com> <20151130172028.GA1088@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20151130172028.GA1088-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Greg KH Cc: Alan Stern , =?UTF-8?Q?Emilio_L=c3=b3pez?= , kborer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, reillyg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jorgelo-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org List-Id: linux-api@vger.kernel.org On 11/30/2015 06:20 PM, Greg KH wrote: > 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... > Yes I have seen such devices (not cdc of course) and they were driven using libusb (vendor specific service + "driver" to bypass publishing protocol code due to kernel's GPL). I have even seen an android app written in java which claims and uses multiple interfaces using android's USB API, so it's real;) -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics