linux-kernel - Re: [Patch] Increase USBFS Bulk Transfer size

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: <20111107214909.GA13023@kroah.com>
Date:	Mon, 7 Nov 2011 13:49:09 -0800
From:	Greg KH <greg@...ah.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Tim Vlaar <Tvlaar@...rey.com>,
	Markus Rechberger <mrechberger@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

On Mon, Nov 07, 2011 at 03:53:59PM -0500, Alan Stern wrote:
> On Mon, 7 Nov 2011, Sarah Sharp wrote:
> 
> > > > Alan, won't this global limit on the usbfs URB buffer size effect
> > > > userspace drivers that are currently allocating large amounts of
> > > > buffers, but still respecting individual buffer limit of 16KB?  It seems
> > > > like the patch has the potential to break userspace drivers.
> > > 
> > > It might indeed.  A further enhancement would replace that 16-MB global
> > > constant with a sysfs attribute (a writable module parameter for
> > > usbcore).  Do you have any better suggestions?
> > 
> > No, I don't have any better suggestions, except take out the limit. ;)
> > 
> > I do understand why we don't want userspace to DoS the system by using
> > up too much DMA'able memory.  However, as I understand it, the usbfs
> > files are created by udev with root access only by default, and distros
> > may choose to install rules that have more permissive privileges.  A
> > device vendor may not be ensured that a udev rule with permissive access
> > will be present for their device, so I think they're likely to write
> > programs that require root access.  Or require root privileges to
> > install said udev rule.
> > 
> > At that point, the same userspace program that has root privileges in
> > order to access usbfs or create the udev rule can just load and unload
> > the usbcore module with an arbitrarily large global limit, and the
> > global limit doesn't really add any security.  So why add the extra
> > barrier?
> 
> This is a question of kernel policy, and I don't know what is the
> generally accepted approach to this sort of thing.  Maybe Greg or Alan
> Cox can comment.

You have to set the limit to something, otherwise a non-root user can
kill the box quite easily.  If the admin wants to set the system up so
that any user can use up all of the memory, they are free to do that,
but we can't have it be the default.

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/