How can i detect the caller process in a minifilter

NTFSD
1

I want to allow specific processes to unload my minifilter driver.
But it seems that the process calling FilterUnloadCallback
is always System.exe…Is there any method for me to detect the actual request process?
And more?how can i detect the actual process communicating to my dirver within the model of communication port.

2

Run these processes under the special user account with proper privileges.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
>I want to allow specific processes to unload my minifilter driver.
> But it seems that the process calling FilterUnloadCallback
> is always System.exe…Is there any method for me to detect the actual request process?
> And more?how can i detect the actual process communicating to my dirver within the model of communication port.
>

3

Well, anyone communicating with your driver using the communication port
must use your communication protocol. You could just add the PID as part of
the request and then you’d know what the PID is in the minifilter.

The reason the unload callback is called by the system process is that a
user mode simply communicates with the OS (the Service Control Manager part
of the OS) to tell it to stop a service. The user mode process doesn’t
actually ever talk to the driver in this case.

If you want to secure communication with the minifilter you could add a
security descriptor to the communication port to ensure that only the
processes you want have access to it. I’m thinking there must also be a way
to set a DACL on the minifilter service to only allow certain users to stop
it (IIRC such functionality exists for user mode services) but I might be
wrong.

Thanks,
Alex.

4

Thanks for your reply.
I want to build secure communication between processes,not users…setting DACL to distinguish
different users will not help. Viewing the example of scanner in WDK, i found that i can get PEPROCESS
of the request process in ConnectNotifyCallback and it really works! Using this structure pointer, i can do filtering jobs now.

5

> I want to build secure communication between processes,not users…

Any security relies on identity checks, and it is very hard to verify the process identity. Using EXE pathname is pathetic since it can be trivially forged.

Probably it is a good idea to look at managed environments like Java and .NET, which do solve this issue of “code identity and access control security based on this”. They use digital signatures of binaries for this, as also on the way the code was started (from webpage script or such).

Probably you can also do the digital signature check of the just-loaded binary in the Ps’s notify callback, and assign some “privileges” of your own based on this.

of the request process in ConnectNotifyCallback and it really works! Using this structure pointer, i can do filtering

This can work, but once again - how do you check the process’s identity? on pathname alone? this is pathetic.

Proper check of the process identity if hard, and more so - it can be broken by the admin-power code which will inject the code to your trusted process and execute it there.

So, you cannot properly protect yourself from the admin-powered adversary. This means that the protection must rely on the fact that the app’s code runs under non-admin user. And, in this case, it is by far enough to mark your driver as “admin-only” and run its companion service as admin/LocalSystem. This will ban any usual apps from unloading your driver, and this is the least expensive - just plain trivial - solution.

Protection from the admin adversaries just plain cannot be done 100% surely. It can only have viscosity but not provide any guarantees. This is how the notion of Windows’s “trusted code base” (i.e. LocalSystem) works (can be broken by the admin adversary creating a service running under LocalSystem) works. The notion of “TrustedInstaller” is the same.

In the worst case, the adversary can boot WinPE/Linux off CD and hack away your protection code.

DRM software goes to this direction well, but it is also a viscosity-based protection, which does not provide 100% logical guarantees, and just makes things harder. For instance, the DRM can make the creation of distributable “unprotected” EXE much harder, if not impossible. Some “cracks” rely on running the companion process which monitors the main process and patches it from time to time on the fly (for instance, some iPhone operator-unlocking cracks were such, more so, they were running in the baseband chip and not in the CPU).

Running in a “jail” (like iPhone OS, Android and most chip firmwares use) is actually the best way to provide the protection against the admin adversary, since in this case there is no user-installable code running under admin at all. But well, Windows is not such. If your code is required to run on consumer commodity Windows - then this is next to impossible, just due to the fact that the PC can be booted off CD, is disassemblable and the hard drive is not encrypted by the software vendor’s private key (unlike the iPhone’s baseband).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

> Maxim S. Shatskih

Thanks for your advise.
It’s almost impossible to guarantee that the communicatin is 100% secure, i knows…
I can just try my best to do identity checks by digital signature and any other method under the assumption that apps are run at non-admin user context.
Injecting or hacking from admin adversaries is not under my consideration, because it is too hard to avoid…