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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151130172028.GA1088@kroah.com>
Date:	Mon, 30 Nov 2015 09:20:28 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Krzysztof Opasiak <k.opasiak@...sung.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Emilio López <emilio.lopez@...labora.co.uk>,
	kborer@...il.com, reillyg@...omium.org, keescook@...omium.org,
	linux-api@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, jorgelo@...omium.org,
	dan.carpenter@...cle.com
Subject: Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/