Hello everyone,

it's been quite a while since I last posted a dumb question in this
newsgroup, so here we go:

I have a vague idea that it would be fine to have a windows service that
applies integrated security to the access of USB devices, namely "USB
Mass Storage Devices". That would mean that I apply a DACL to some
object (a device instance?) so that user mode client applications can
only access the file system on the USB device if the DACL allows it.

Please feel free to comment if what I describe here or if the terms I
use are stupid - you are the kernel guys and I am a user mode guy with
only a fuzzy feeling of what might be possible in this realm.

My idea is to set a DACL via SetupDiSetClassRegistryProperty or
SetupDiSetDeviceRegistryProperty as described here by Karan Mehra:

http://groups.google.de/group/micros...acefbfa73a4370

But I think the only criterion to see if a device instance is a "USB
Mass Storage Devices" (and therefore to apply a DACL) is to see if it
uses usbstor.sys. Right?

Therefore I think I have to enumerate all devices and see if they use
usbstor.sys. I borrowed some code from Elyias' devcon.exe that retrieves
the files that a device instance is using but it is terribly sloooooww.
On my Pentium III here it takes about 1 minute to execute "devcon
driverfiles *" and in my own code (which currently uses cfgmgr-API for
enumeration to have a tree structure) it takes almost 2 minutes for the
enumeration of all devices and the dtermination of their files. Is there
any faster way to determine which driver files a device instance is
using than this (user mode only)?

Is this at all a viable approach to solve the problem (regulate access
to USB drives with a DACL)?

Any comment welcome,

--
Stefan Kuhr

If the filesystem is mounted to the device, then its DACL is just plain
ignored.

So, FAT on the USB floppy cannot be protected this way. Write an FS filter
which will ask for the bus type of the underlying disk and disable MJ_CREATE
for not-so-privileged user and USB disk.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Stefan Kuhr" <kustt110@gmx.li> wrote in message
news:43CD846E.565EC1DC@gmx.li...

Hello Maxim,

"Maxim S. Shatskih" wrote:

Isn't this problem taken care for in what Karan Mehra described in the
link I mentioned with the FILE_DEVICE_SECURE_OPEN characteristic? This
is the quote from Karan:

"So, to sum, you should set an appropriate ACL on either a specific
device
(or all devices of a certain class) via the above mentioned APIs and
then
further lock down the namespace by setting the FILE_DEVICE_SECURE_OPEN
characteristic via the SPCRP_CHARACTERISTICS property"

Or do you describe a big race condition in that the user plugs in a USB
device and it will already be too late if my service-thingie applies the
above to the device object because a file system will be immediately
mounted and after mounting the file system the DACL will be ignored?
Maybe it will only become effective if the user unplugs the device and
plugs it in again?

--
Stefan Kuhr

Hello Maxim,

Maxim S. Shatskih wrote:
Another question: Does writing an FS filter involve ordering the IFS kit
and is it subject to all things that seem to be common knowledge with
respect to the IFS kit (like "You need years of experience in windows
kernel mode device driver writing and for such a thing you need one year
development time" and similar warnings that I frequently read in this
newsgroup regarding anything with the IFS kit)?

And maybe you can answer my other question that I asked you in this thread?

I appreciate your comments.


--
Stefan Kuhr

"Lesen schadet der Dummheit"