Re: Less strict requirement for USB_REQUEST ioctl
On 30/07/15(Thu) 12:18, Ludovic Coues wrote: Right now, an USB_REQUEST ioctl will fail with an EBADF error if done on a device opened as read-only. With this patch, the ioctl will fail only if the USB_REQUEST is a write request. Do you need this to be able to use your usbdevs-like tool as a normal use with the w bit on a /dev/usb node? Index: sys/dev/usb/usb.c === RCS file: /cvs/src/sys/dev/usb/usb.c,v retrieving revision 1.107 diff -u -p -r1.107 usb.c --- sys/dev/usb/usb.c 14 Mar 2015 03:38:50 - 1.107 +++ sys/dev/usb/usb.c 26 Jul 2015 16:16:52 - @@ -618,7 +618,8 @@ usbioctl(dev_t devt, u_long cmd, caddr_t usbd_status err; int error = 0; - if (!(flag FWRITE)) + if ((flag FWRITE) == 0 + (ur-ucr_request.bmRequestType UT_READ) == 0) return (EBADF); DPRINTF((usbioctl: USB_REQUEST addr=%d len=%d\n, addr, len));
Re: Less strict requirement for USB_REQUEST ioctl
ludovic coues schreef op 2015-08-10 23:29: 2015-08-10 22:56 GMT+02:00 Martin Pieuchot m...@openbsd.org: On 30/07/15(Thu) 12:18, Ludovic Coues wrote: Right now, an USB_REQUEST ioctl will fail with an EBADF error if done on a device opened as read-only. With this patch, the ioctl will fail only if the USB_REQUEST is a write request. Do you need this to be able to use your usbdevs-like tool as a normal use with the w bit on a /dev/usb node? In the case a user have the read right on the node without the write right, this patch would allow the normal use of my usbdevs-like tools for this user. In a system with default permission, this won't change anything as root and wheel have read + write permission on /dev/usb nodes and everybody else have nothing. Well, the point is that the USB_REQUEST ioctl sends a command to the device. In that sense, it always involves a write to the device even if the command issued is a read command. The fact that there is only data transfer from the device to the host doesn't mean it doesn't affect the state of the device. I think the current code is right. If you open the node read-only, you only get to see the kernel state for the device. If you open with write permission, you get full control over the device.
Re: Less strict requirement for USB_REQUEST ioctl
2015-08-10 22:56 GMT+02:00 Martin Pieuchot m...@openbsd.org: On 30/07/15(Thu) 12:18, Ludovic Coues wrote: Right now, an USB_REQUEST ioctl will fail with an EBADF error if done on a device opened as read-only. With this patch, the ioctl will fail only if the USB_REQUEST is a write request. Do you need this to be able to use your usbdevs-like tool as a normal use with the w bit on a /dev/usb node? In the case a user have the read right on the node without the write right, this patch would allow the normal use of my usbdevs-like tools for this user. In a system with default permission, this won't change anything as root and wheel have read + write permission on /dev/usb nodes and everybody else have nothing. -- Cordialement, Coues Ludovic +336 148 743 42
Re: Less strict requirement for USB_REQUEST ioctl
ludovic coues schreef op 2015-08-10 23:29: 2015-08-10 22:56 GMT+02:00 Martin Pieuchot m...@openbsd.org: On 30/07/15(Thu) 12:18, Ludovic Coues wrote: Right now, an USB_REQUEST ioctl will fail with an EBADF error if done on a device opened as read-only. With this patch, the ioctl will fail only if the USB_REQUEST is a write request. Do you need this to be able to use your usbdevs-like tool as a normal use with the w bit on a /dev/usb node? In the case a user have the read right on the node without the write right, this patch would allow the normal use of my usbdevs-like tools for this user. In a system with default permission, this won't change anything as root and wheel have read + write permission on /dev/usb nodes and everybody else have nothing. Well, the point is that the USB_REQUEST ioctl sends a command to the device. In that sense, it always involves a write to the device even if the command issued is a read command. The fact that there is only data transfer from the device to the host doesn't mean it doesn't affect the state of the device. I think the current code is right. If you open the node read-only, you only get to see the kernel state for the device. If you open with write permission, you get full control over the device. Essentially the OP wants to completely remove the security model, running unknown lines of code in the kernel, and in the firmware of the actual device, causing unknown responses to trigger bugs on the underside of the USB stack. Then why not open it as root? Oh, because you have no root privilege to exercise those code paths on purpose. That's the whole idea of this seperation. Do you understand?
