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]

Date:	Mon, 30 Nov 2015 11:16:02 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Krzysztof Opasiak <k.opasiak@...sung.com>
cc:	Greg KH <gregkh@...uxfoundation.org>,
	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 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-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/