none
KMDF: Toaster sample bus driver, want to open from user privileges. RRS feed

  • Question

  • Hi, everybody.

    Tell please, whether is possible access to the interface of the bus-driver, having only the user privileges?

    Because using the user space ENUM application (from the Toaster sample) I can open GUID_DEVINTERFACE_BUSENUM_TOASTER only from admin rights..

    Q:

    1. What I need to change in an example of Toaster bus-driver to make CreateFile() from the user without permission error (#5)? Whether it is possible?

    2. May I do IOCTL_BUSENUM_(UN)PLUGIN_HARDWARE ioctl (from the Toaster sample) from the user rights for adding/remove to the bus the new device? Whether it is possible?

    Best regards, Denis

    Monday, September 2, 2013 6:25 PM

Answers

  • You can do this, but you need to think if you really want to.  You are basically controlling a system component and saying anyone can do that. 

    In Bus_EvtDeviceAdd you need to add a call to WdfDeviceInitAssignSDDLString to the device setup for the device using an SDDL that will allow all users to access the device.

    As I say, think about what you are doing, if this is a bus driver for something being distributed don't do this you are opening a security hole.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, September 2, 2013 6:39 PM

All replies

  • You can do this, but you need to think if you really want to.  You are basically controlling a system component and saying anyone can do that. 

    In Bus_EvtDeviceAdd you need to add a call to WdfDeviceInitAssignSDDLString to the device setup for the device using an SDDL that will allow all users to access the device.

    As I say, think about what you are doing, if this is a bus driver for something being distributed don't do this you are opening a security hole.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, September 2, 2013 6:39 PM
  • As I say, think about what you are doing, if this is a bus driver for something being distributed don't do this you are opening a security hole.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Mr. Don, many thanks,  for your response.

    Yes, I everything understand it...

    But I wanted to implement monitoring/sniffing of all I/O of child FDO devices through bus-driver's event handle (through DeviceIoControl & WaitForMultipleObjects).

    I.e., I planned to create user space application which through DeviceIoControl to the interface of the bus-driver could request, e.g. number of child devices and so forth, and also catch all I/O from desired child device.

    I read about:

    1. Control Device Object: http://msdn.microsoft.com/en-us/library/windows/hardware/ff545424%28v=vs.85%29.aspx

    2. Filter driver: http://msdn.microsoft.com/en-us/library/windows/hardware/ff545890%28v=vs.85%29.aspx

    But I is confused and I don't know what to me to use. Because anywhere I not found an concrete recommendations, regarding my issue.

    Issue:

    1. User through DeviceIoControl must able to add/remove of MY_FDO_device from/to MY_bus

    2. User through DeviceIoControl must able to request some info-list of available MY_FDO_devices on MY_bus

    3. User through DeviceIoControl must able to change some properties/configuraton/behavior of desired MY_FDO_device without open it

    4. User through DeviceIoControl must able to monitor any I/O events of desired MY_FDO_device

    Tell please, what usually the way is used for the issue?


    Best regards, Denis

    Monday, September 2, 2013 7:24 PM
  • Well assuming you are using a kernel mode driver framework (or the 8.1 UMDF) then as I said: "In Bus_EvtDeviceAdd you need to add a call to WdfDeviceInitAssignSDDLString with an SDDL that allows regular users to manage things."

    I'm not sure what your are doing since if you are creating the function drivers (which you are likely to be doing) then it would be easier and safer to put much of this functionality in the function driver.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, September 2, 2013 7:33 PM
  • Mr. Don,

    Earlier I planned to create the bus-driver and separate function driver (as in the Toaster sample), but now with:

    > I'm not sure what your are doing since if you are creating the function drivers (which you are likely to be doing) then it would be easier and safer to put much of this functionality in the function driver.

    I'am not sure...

    So, you mean, that it is better, instead of bus driver to use function driver? I.e. in this case the functional driver will have the list of childs FDO's?

    You can explain in more detail that you mean?

    Please.... :)

    Best regards, Denis




    • Edited by kuzulis Monday, September 2, 2013 7:46 PM
    Monday, September 2, 2013 7:43 PM
  • Well if all the FDO's are the same, I would do it in the function driver by adding a control device to the function driver.  For all the other calls you need to do them in the function driver, since the bus driver will not see things like I/O events to the function driver.

    What you would need to do is create a device contexct in the function driver that includes a linked list to other contexts, and which has a delete routine to unlink the specific context.  Then you can use a global list head to walk that list and return the results in the control device.

    This will do everything you want except allow creating of more PDO's.  I don't understand why you want that dynamic in that way since this is a very rarely used model (i.e. user space creating PDO's).  Explain the problem you are trying to solve with creating the PDO's and perhaps there is a secure solution.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, September 2, 2013 8:08 PM
  • what devices are you interested in filtering? your own devices that you enumerate? or other stacks that you think your bus driver will somehow get you access to?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, September 3, 2013 3:52 AM
  • also consider assigning the security in the INF that installs the bus driver. it is simpler to maintain and easier to understand.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, September 3, 2013 3:52 AM
  • Mr. Don,

    > Explain the problem you are trying to solve with creating the PDO's and perhaps there is a secure solution.

    Mr. Doron,

    > what devices are you interested in filtering? your own devices that you enumerate? or other stacks that you think your bus driver will somehow get you access to?

    My problem is banal...

    My purpose - to create user app which can dynamically create or delete pairs of virtual serial ports. Two virtual serial ports in each pair are programmatically connected among themselves (something like null-modem connection). Besides, the user app has to be able "attach" to any of the created virtual serial ports and intercept/catch all I/O traffic.

    For this purpose I want to use an KMDF model because I want that there was an opportunity to use third-party sniffers (filter drivers) from other vendors. Because the WDM/KMDF filter drivers can't attached to the UMDF device, if I'm not mistake.

    I.e. I want to make something similar:

    Com0Com

    HDD Free Virtual Serial Ports

    Eltima Virtual Serial Ports Pairs

    and so on.

    Having once again reconsidered an sample from Toaster, I came to a conclusion that it is necessary to do so:

    1) Use the KMDF  bus driver "MY_bus" to plug/unplug/control for virtual serial ports PDO's.

    Functionality :

    - plug child device (virtual serial port)

    - unplug child device (virtual serial port)

    - get list of attached child devices (virtual serial ports)

    - set some properties to desired attached child device (virtual serial port)

    Of course, these DeviceIoControls will be executed from an admins rights (let will be so, without WdfDeviceInitAssignSDDLString).

    2) Use the KMDF function driver "MY_virtual_port" to main virtual serial port implementation.

    3) Use the filter driver "MY_filter" to ability to catch/sniff and transfer to user app all I/O from the desired virtual serial port.

    Of course, these DeviceIoControls will be executed from an user rights (yes?).

    I.e., as a result it is required to create three drivers. I correctly understand the idea? Or it is possible to decide it somehow differently?

    Best regards, Denis

    Tuesday, September 3, 2013 7:46 AM