Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1280192

Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers

From Krzysztof Opasiak <k.opasiak@samsung.com>
Newsgroups linux.kernel
Subject Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers
Date 2015-11-30 19:50 +0100
Message-ID <qABGp-7gu-9@gated-at.bofh.it> (permalink)
References <qAzlg-5Uw-33@gated-at.bofh.it> <qAAhk-6vu-23@gated-at.bofh.it> <qAAr1-6zg-43@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Emilio López <emilio.lopez@collabora.co.uk> - 2015-11-25 16:50 +0100
  [PATCH v1] usb: devio: Add ioctl to disallow detaching kernel USB drivers. Emilio López <emilio.lopez@collabora.co.uk> - 2015-11-25 16:50 +0100
    Re: [PATCH v1] usb: devio: Add ioctl to disallow detaching kernel  USB drivers. Dan Carpenter <dan.carpenter@oracle.com> - 2015-11-26 10:30 +0100
  Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Krzysztof Opasiak <k.opasiak@samsung.com> - 2015-11-26 10:30 +0100
    Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Greg KH <gregkh@linuxfoundation.org> - 2015-11-26 18:30 +0100
      Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Krzysztof Opasiak <k.opasiak@samsung.com> - 2015-11-27 09:50 +0100
        Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Greg KH <gregkh@linuxfoundation.org> - 2015-11-28 03:40 +0100
          Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Oliver Neukum <oneukum@suse.com> - 2015-11-30 10:20 +0100
        Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Alan Stern <stern@rowland.harvard.edu> - 2015-11-30 17:20 +0100
          Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Krzysztof Opasiak <k.opasiak@samsung.com> - 2015-11-30 18:20 +0100
            Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Greg KH <gregkh@linuxfoundation.org> - 2015-11-30 18:30 +0100
              Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers Krzysztof Opasiak <k.opasiak@samsung.com> - 2015-11-30 19:50 +0100

csiph-web