linux-kernel - Re: usbfs, claiming entire usb devices

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: <Pine.LNX.4.44L0.0905071714220.4812-100000@iolanthe.rowland.org>
Date:	Thu, 7 May 2009 17:18:50 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Kay Sievers <kay.sievers@...y.org>
cc:	Kernel development list <linux-kernel@...r.kernel.org>,
	Pantelis Koukousoulas <pktoss@...il.com>,
	USB list <linux-usb@...r.kernel.org>
Subject: Re: usbfs, claiming entire usb devices

On Thu, 7 May 2009, Kay Sievers wrote:

> On Thu, May 7, 2009 at 21:55, Alan Stern <stern@...land.harvard.edu> wrote:
> > There is a proposal afoot to give user programs the ability to claim
> > ownership of an entire USB device, rather than just individual
> > interfaces. Â In fact, we'd like processes to be able to own whatever
> > device gets plugged into a particular port on a particular hub.
> >
> > The question is how the API should work. Â A simple approach is to have
> > a sysfs or usbfs file correspond to each port; when a process opens the
> > file it would be granted ownership of any device plugged into that
> > port. Â Since the file is automatically closed when the process ends, we
> > wouldn't have to worry about ownership never getting released.
> >
> > But there's a snag. Â When a process goes to open the usbfs file for a
> > device, the kernel needs to know whether or not the process owns that
> > device. Â In other words, we need to figure out whether or not the
> > process has opened the corresponding port file.
> >
> > Is there a simple way to do this? Â Is it reasonable to search through
> > all the process's fd's, looking for one that matches a particular
> > inode?
> >
> > Or would a completely different API approach be better?
> 
> You have one file per device, and that file has normal unix file
> permissions. Userspace can grant access to that file by ownership or
> by adding an ACL. What else do we need?

We need the ability to prevent the kernel from automatically 
configuring a device.  We need the ability to prevent kernel drivers 
from binding to a device before userspace programs get a chance.

>  Why would the kernel care who
> opened the file, when the one was able to get through the normal file
> access check?

Access checks can't be used, because programs want to stake their claim
to the device (and its file) even before the device has been plugged
in.  So there's no file and no ACL to set.

> Or did you mean some magic for an entire tree of devices below some
> port? Like some sort of permission inheritance in the kernel?

No, just the device in that port.

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/