Hello,
I’m looking to filter service creation and named pipe access. Unfortunately it looks like minifilters can’t attach to NPFS/MSFS but is there any other “official” workaround? My primary goal is to detect/deny processes creating services. Ideally this would take place by monitoring the registry with the Cm* callbacks, but that is unfortunately out-of-band as the registry entries are created by services.exe after an RPC call and it does not give visibility into processes simply starting services. Usermode hooking is unreliable but may need to be used if there are no 32bit-64bit solutions available.
Are there any other approaches that I could look into for monitoring RPC calls/named pipe communication/mailslots?
Thank you for your time!
> Are there any other approaches that I could look into for monitoring RPC
calls/named pipe communication/mailslots?
Nathan,
Legacy file system filters are your friend. You would likely have better luck talking about this subject on the NTFSD list.
Hope that helps,
Ilya Faenson
Rockville, MD USA
> I’m looking to filter service creation and named pipe access. Unfortunately it looks like minifilters can’t
attach to NPFS/MSFS but is there any other “official” workaround?
Legacy filter.
entries are created by services.exe after an RPC call and it does not give visibility into processes
simply starting services.
Why just not rely on user-identity-based protection provided by Windows?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> Why just not rely on user-identity-based protection provided by Windows?
Because user based security seems no longer be relevant.
The “endpoint security” market seems to view various applications and
services
from various vendors as different subjects, even though they all run under
one
user account, in same session.
For example, they may want to treat browser plugins as separate entities
from each others, and the browser itself.
For whatever reason, they don’t consider software restriction policies
provided by the OS as a good solution.
Perhaps this is just a fashion with no technical legs, but, as we’ve seen
recently, fashion is a material force.
Regards,
– pa
For whatever reason, they don’t consider software restriction policies provided by the OS as a good solution. Perhaps this is just a fashion with no technical legs, but, as we’ve seen recently, fashion is a material force.
Very well put, Pavel.
mm
wrote in message news:xxxxx@ntdev…
> For whatever reason, they don’t consider software restriction policies
> provided by the OS as a good solution. Perhaps this is just a fashion
> with no technical legs, but, as we’ve seen recently, fashion is a material
> force.
>
> Very well put, Pavel.
and learned in a hard way 
thanks, Martin.
– pa
Thank you all for the assistance so far. I’ve created a small legacy filter and am looking at the file object on each received IRP which is working fine at tracking named pipes/mailslots that I’ve created as a test in usermode. However, it isn’t seeing service manager I/O for whatever reason, despite looking at the file object on all IRP types. My research so far has shown that calls “should” be going through named pipes when manipulating services so I’m a bit perplexed as to why this isn’t picking it up.
Has anyone looked at this side of the service manager before and am I missing anything obvious? I’m filtering \Device\NamedPipe and \Device\MailSlot and quite honestly am not seeing any other device that I should be filtering, although I very possibly could be overlooking something.
Thank you for the assistance!
(Also, Pavel, I agree with your points about SRP but unfortunately the bulk of users are blind to this and there is a desire for more seamless workarounds than to block applications in general or to force the user to be a Standard User)
A lot of system RPC uses LPC and not named pipes.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@gmail.com
Sent: Wednesday, May 19, 2010 7:52 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Monitoring service creation/RPC/Named Pipes
Thank you all for the assistance so far. I’ve created a small legacy filter
and am looking at the file object on each received IRP which is working fine
at tracking named pipes/mailslots that I’ve created as a test in usermode.
However, it isn’t seeing service manager I/O for whatever reason, despite
looking at the file object on all IRP types. My research so far has shown
that calls “should” be going through named pipes when manipulating services
so I’m a bit perplexed as to why this isn’t picking it up.
Has anyone looked at this side of the service manager before and am I
missing anything obvious? I’m filtering \Device\NamedPipe and
\Device\MailSlot and quite honestly am not seeing any other device that I
should be filtering, although I very possibly could be overlooking
something.
Thank you for the assistance!
(Also, Pavel, I agree with your points about SRP but unfortunately the bulk
of users are blind to this and there is a desire for more seamless
workarounds than to block applications in general or to force the user to be
a Standard User)
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>as a test in usermode. However, it isn’t seeing service manager I/O for whatever reason
Probably this goes via LPC ports.
Disassemble advapi32!StartServiceControlDispatcher and look.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com