The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
(This is a bit long, please bear with me)
I am using a minifilter driver to help me implement a Windows
file access control system that has the following components:
The basic design works as follows(ignoring minifilter driver config ops):
1. Windows user tries to open a file on a share.
2. In its PreCreate handler, a minifilter driver gets the file name and
determines if the file is on the target share. If so, it logs the file
open request (PID/process name) to an user application, passing through
file requests that target other volumes. The PreCreate handler waits for
an application ack before returning.
3. The user application puts the shared file open request on a queue, say,
file_log_list, before calling FilterReplyMessage() to ack the driver.
4. The Samba server receives the file open request and issues its own open
request to the Linux FS. I have a Linux FS monitor application watching
the shares, receiving notifications on the Samba server's file requests.
5. My Linux FS monitor application sends the file request (share/file name)
to the Windows client originating the file open request.
6. The Windows application scans the file log queue for the target file
and returns the originating Windows process executable and its digital
signature info to the Linux FS monitor application.
7. The Linux FS monitor application uses a Windows application white list
to determine if the open request should be allowed and the decision is
injected into the Linux FS which eventually returns the open request
result back to the Windows client.
8. In its PostCreate handler, the minifilter driver pretty much just
print out the IoStatus.Status value for debugging purpose.
This design works for some applications. For example, only MS Office
can open the Office files if that is what the white list policy wants.
Here is the problem that I don't know how to approach and I am hoping for
advice from folks here:
If I run Visual Studio to build a project in the shared folder,
the executable file can be created but attempt to run from the VS would
fail. A "hello world" console app would open a window without printing
any message. I have added all VS exe's to the white list. In fact, the
following tests all work:
1. If I copy the generated EXE to the desktop and run from there.
2. If I just white-list everything and do not load the minifilter driver.
3. If I attach the minispy driver to the network share, replacing my own driver.
I'd really appreciate it if any of you can give me some hints, or completely
different methods to solve this kind of network file access control
problem. The requirement is to allow the server to use client program
white list to authenticate client file access.
Unfortunately, Windows doesn't have an equivalent to the Linux fanotify API,
which is why I had to use a minifilter driver to get notifications of file access events.
Thank you very much!
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Writing WDF Drivers||7 Dec 2020||LIVE ONLINE|
|Internals & Software Drivers||25 Jan 2021||LIVE ONLINE|
|Developing Minifilters||8 March 2021||LIVE ONLINE|