WFP and user-mode

NTDEV
1

Hi all

we’re looking at WFP to replace a current LSP project.

Currently the LSP relies on the fact that it’s loaded in the user
context, so has:

* ability to auth using SSPI with our server using current windows user
credentials
* ability to pop up a dialog to the user running the winsock app (e.g.
login creds dialog, warning, message etc)

The WFP docs state that WFP is intended to allow replacing LSP with WFP
apps/drivers/whathaveyou

My question is, is there any way to get access back to the user that is
running the application?

I presume from a WFP callout driver in the kernel, you can no longer
rely on being in the context of any user thread (e.g. may be in
rescheduled kernel worker thread?).

So is there any way to get callouts from user mode? Presumably the
ipsec and RPC runtime filters do this, and are registered somehow with
the Base Filtering Engine.

Alternatively, if you can rely on being in the user context even only at
a not-particularly useful level, could you get say the user window
station, and pass that back to some user mode service to push a dialog
into that window station?

Or am I stuck with an LSP approach for this?

Thanks in advance.

Adrien

2

First of all, LSP’s are deprecated starting with Windows 8. That doesn’t necessarily mean that they won’t work, but they are certainly on the way out. There are some HCK tests that explicitly check for “no TDI and no LSP”.

Many WFP callouts include fairly rich meta-data that identifies caller process information, etc. You should be able to invent an I/O scheme that allow your app to inform your WFP driver of its process information, which should allow your WFP driver to know what to do.

PsSetCreateProcessNotifyRoutineEx and friends may also help you in process tracking even without adding an app<->driver communication path.

Should be doable, except for the user interaction. There you would need your application’s help.

No, I haven’t done it, so your mileage may vary…

Good luck!

Thomas F. Divine

http://www.pcausa.com

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Adrien de Croy
Sent: Wednesday, January 8, 2014 4:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WFP and user-mode

Hi all

we’re looking at WFP to replace a current LSP project.

Currently the LSP relies on the fact that it’s loaded in the user context, so has:

* ability to auth using SSPI with our server using current windows user credentials

* ability to pop up a dialog to the user running the winsock app (e.g. login creds dialog, warning, message etc)

The WFP docs state that WFP is intended to allow replacing LSP with WFP apps/drivers/whathaveyou

My question is, is there any way to get access back to the user that is running the application?

I presume from a WFP callout driver in the kernel, you can no longer rely on being in the context of any user thread (e.g. may be in rescheduled kernel worker thread?).

So is there any way to get callouts from user mode? Presumably the ipsec and RPC runtime filters do this, and are registered somehow with the Base Filtering Engine.

Alternatively, if you can rely on being in the user context even only at a not-particularly useful level, could you get say the user window station, and pass that back to some user mode service to push a dialog into that window station?

Or am I stuck with an LSP approach for this?

Thanks in advance.

Adrien

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

3

Hi Thomas

thanks for your explanation.

Ideally we’d be able to run for a bit in the user thread context, since
there’s no other way to use SSPI to auth to a remote server without
bothering the user. If we can’t run in the user thread, we have to ask
the user to re-type their windows creds (which will be a pain and
support burden).

When registering a session for the BFE, it holds the PID, user SID etc.
But problem with that is it won’t be able to distinguish the particular
user by SID only, e.g. in a terminal services environment you can have
multiple people logged in using the same user account, they will have
the same SID, but you don’t want messages for one user going to another
and vice versa. So you’d really need the window station.

There are some user mode filter layers. But all seem to be related to
filtering RPC calls to the BFE. I presume windows sockets doesn’t now
all go via RPC via the BFE?

Regards

Adrien

------ Original Message ------
From: “Thomas F. Divine”
To: “Windows System Software Devs Interest List”
Sent: 09/01/2014 11:20:15
Subject: RE: [ntdev] WFP and user-mode

>First of all, LSP’s are deprecated starting with Windows 8. That
>doesn’t necessarily mean that they won’t work, but they are certainly
>on the way out. There are some HCK tests that explicitly check for “no
>TDI and no LSP”.
>
>
>
>Many WFP callouts include fairly rich meta-data that identifies caller
>process information, etc. You should be able to invent an I/O scheme
>that allow your app to inform your WFP driver of its process
>information, which should allow your WFP driver to know what to do.
>
>
>
>PsSetCreateProcessNotifyRoutineEx and friends may also help you in
>process tracking even without adding an app<->driver communication
>path.
>
>
>
>Should be doable, except for the user interaction. There you would need
>your application’s help.
>
>
>
>No, I haven’t done it, so your mileage may vary…
>
>
>
>Good luck!
>
>
>
>Thomas F. Divine
>
>http://www.pcausa.com<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;From:xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Adrien de Croy
>Sent: Wednesday, January 8, 2014 4:58 PM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] WFP and user-mode
>
>
>
>Hi all
>
>
>
>we’re looking at WFP to replace a current LSP project.
>
>
>
>Currently the LSP relies on the fact that it’s loaded in the user
>context, so has:
>
>
>
>* ability to auth using SSPI with our server using current windows user
>credentials
>
>* ability to pop up a dialog to the user running the winsock app (e.g.
>login creds dialog, warning, message etc)
>
>
>
>The WFP docs state that WFP is intended to allow replacing LSP with WFP
>apps/drivers/whathaveyou
>
>
>
>My question is, is there any way to get access back to the user that is
>running the application?
>
>
>
>I presume from a WFP callout driver in the kernel, you can no longer
>rely on being in the context of any user thread (e.g. may be in
>rescheduled kernel worker thread?).
>
>
>
>So is there any way to get callouts from user mode? Presumably the
>ipsec and RPC runtime filters do this, and are registered somehow with
>the Base Filtering Engine.
>
>
>
>Alternatively, if you can rely on being in the user context even only
>at a not-particularly useful level, could you get say the user window
>station, and pass that back to some user mode service to push a dialog
>into that window station?
>
>
>
>Or am I stuck with an LSP approach for this?
>
>
>
>Thanks in advance.
>
>
>
>Adrien
>
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
>OSR is HIRING!! See http://www.osr.com/careers
>
>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
>
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
>OSR is HIRING!! See http://www.osr.com/careers
>
>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

4

PsSetCreateProcessNotifyRoutineEx may be able to help fetching the SID.

Also, be sure to take a look at the monumental “Windows Filtering Platform” sample that can be downloaded from the MSDN. (Kudos to Dusty Harper for writing it!) I found it difficult to follow and uses implementation techniques I probably wouldn’t use myself, but it illustrates a LOT of WFP techniques. Also, don’t overlook the SDK WFP samples.

Good luck! Sounds like an interesting task.

Thomas F. Divine

http: http://www.pcausa.com

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Adrien de Croy
Sent: Wednesday, January 8, 2014 5:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WFP and user-mode

Hi Thomas

thanks for your explanation.

Ideally we’d be able to run for a bit in the user thread context, since there’s no other way to use SSPI to auth to a remote server without bothering the user. If we can’t run in the user thread, we have to ask the user to re-type their windows creds (which will be a pain and support burden).

When registering a session for the BFE, it holds the PID, user SID etc. But problem with that is it won’t be able to distinguish the particular user by SID only, e.g. in a terminal services environment you can have multiple people logged in using the same user account, they will have the same SID, but you don’t want messages for one user going to another and vice versa. So you’d really need the window station.

There are some user mode filter layers. But all seem to be related to filtering RPC calls to the BFE. I presume windows sockets doesn’t now all go via RPC via the BFE?

Regards

Adrien

------ Original Message ------

From: “Thomas F. Divine” < mailto:xxxxx xxxxx@gmail.com>

To: “Windows System Software Devs Interest List” < mailto:xxxxx xxxxx@lists.osr.com>

Sent: 09/01/2014 11:20:15

Subject: RE: [ntdev] WFP and user-mode

First of all, LSP’s are deprecated starting with Windows 8. That doesn’t necessarily mean that they won’t work, but they are certainly on the way out. There are some HCK tests that explicitly check for “no TDI and no LSP”.

Many WFP callouts include fairly rich meta-data that identifies caller process information, etc. You should be able to invent an I/O scheme that allow your app to inform your WFP driver of its process information, which should allow your WFP driver to know what to do.

PsSetCreateProcessNotifyRoutineEx and friends may also help you in process tracking even without adding an app<->driver communication path.

Should be doable, except for the user interaction. There you would need your application’s help.

No, I haven’t done it, so your mileage may vary…

Good luck!

Thomas F. Divine

http:</http:> http://www.pcausa.com

From: mailto:xxxxx xxxxx@lists.osr.com [mailto: mailto:xxxxx xxxxx@lists.osr.com] On Behalf Of Adrien de Croy
Sent: Wednesday, January 8, 2014 4:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WFP and user-mode

Hi all

we’re looking at WFP to replace a current LSP project.

Currently the LSP relies on the fact that it’s loaded in the user context, so has:

* ability to auth using SSPI with our server using current windows user credentials

* ability to pop up a dialog to the user running the winsock app (e.g. login creds dialog, warning, message etc)

The WFP docs state that WFP is intended to allow replacing LSP with WFP apps/drivers/whathaveyou

My question is, is there any way to get access back to the user that is running the application?

I presume from a WFP callout driver in the kernel, you can no longer rely on being in the context of any user thread (e.g. may be in rescheduled kernel worker thread?).

So is there any way to get callouts from user mode? Presumably the ipsec and RPC runtime filters do this, and are registered somehow with the Base Filtering Engine.

Alternatively, if you can rely on being in the user context even only at a not-particularly useful level, could you get say the user window station, and pass that back to some user mode service to push a dialog into that window station?

Or am I stuck with an LSP approach for this?

Thanks in advance.

Adrien

—
NTDEV is sponsored by OSR

Visit the list at: http: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http: http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http: http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

Visit the list at: http: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http: http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http: http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</http:></http:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></http:>

5

The effective sid of a thread is not static – impersonation can cause a different security context from that of the process to be presented at any later time. Assuming that all threads in a process use the same security context as the process default access token is not a good idea, and likely to lead to security problems later on down the line.

  • S (Msft)

From: Thomas F. Divinemailto:xxxxx
Sent: ?1/?8/?2014 15:04
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] WFP and user-mode

PsSetCreateProcessNotifyRoutineEx may be able to help fetching the SID.

Also, be sure to take a look at the monumental ?Windows Filtering Platform? sample that can be downloaded from the MSDN. (Kudos to Dusty Harper for writing it!) I found it difficult to follow and uses implementation techniques I probably wouldn?t use myself, but it illustrates a LOT of WFP techniques. Also, don?t overlook the SDK WFP samples.

Good luck! Sounds like an interesting task.

Thomas F. Divine
http://www.pcausa.com

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Adrien de Croy
Sent: Wednesday, January 8, 2014 5:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WFP and user-mode

Hi Thomas

thanks for your explanation.

Ideally we’d be able to run for a bit in the user thread context, since there’s no other way to use SSPI to auth to a remote server without bothering the user. If we can’t run in the user thread, we have to ask the user to re-type their windows creds (which will be a pain and support burden).

When registering a session for the BFE, it holds the PID, user SID etc. But problem with that is it won’t be able to distinguish the particular user by SID only, e.g. in a terminal services environment you can have multiple people logged in using the same user account, they will have the same SID, but you don’t want messages for one user going to another and vice versa. So you’d really need the window station.

There are some user mode filter layers. But all seem to be related to filtering RPC calls to the BFE. I presume windows sockets doesn’t now all go via RPC via the BFE?

Regards

Adrien

------ Original Message ------
From: “Thomas F. Divine” >
To: “Windows System Software Devs Interest List” >
Sent: 09/01/2014 11:20:15
Subject: RE: [ntdev] WFP and user-mode

First of all, LSP?s are deprecated starting with Windows 8. That doesn?t necessarily mean that they won?t work, but they are certainly on the way out. There are some HCK tests that explicitly check for ?no TDI and no LSP?.

Many WFP callouts include fairly rich meta-data that identifies caller process information, etc. You should be able to invent an I/O scheme that allow your app to inform your WFP driver of its process information, which should allow your WFP driver to know what to do.

PsSetCreateProcessNotifyRoutineEx and friends may also help you in process tracking even without adding an app<->driver communication path.

Should be doable, except for the user interaction. There you would need your application?s help.

No, I haven?t done it, so your mileage may vary?

Good luck!

Thomas F. Divine
http://www.pcausa.comhttp:</http:>

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of Adrien de Croy
Sent: Wednesday, January 8, 2014 4:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WFP and user-mode

Hi all

we’re looking at WFP to replace a current LSP project.

Currently the LSP relies on the fact that it’s loaded in the user context, so has:

* ability to auth using SSPI with our server using current windows user credentials
* ability to pop up a dialog to the user running the winsock app (e.g. login creds dialog, warning, message etc)

The WFP docs state that WFP is intended to allow replacing LSP with WFP apps/drivers/whathaveyou

My question is, is there any way to get access back to the user that is running the application?

I presume from a WFP callout driver in the kernel, you can no longer rely on being in the context of any user thread (e.g. may be in rescheduled kernel worker thread?).

So is there any way to get callouts from user mode? Presumably the ipsec and RPC runtime filters do this, and are registered somehow with the Base Filtering Engine.

Alternatively, if you can rely on being in the user context even only at a not-particularly useful level, could you get say the user window station, and pass that back to some user mode service to push a dialog into that window station?

Or am I stuck with an LSP approach for this?

Thanks in advance.

Adrien

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

6

Note that SSPI functions can be used as long as you can capture an impersonation token. Depending on your design, the default process token may suffice, but certainly you do not need to run code in any specific thread to make this work.

“Adrien de Croy” wrote in message news:xxxxx@ntdev…

Hi Thomas

thanks for your explanation.

Ideally we’d be able to run for a bit in the user thread context, since there’s no other way to use SSPI to auth to a remote server without bothering the user. If we can’t run in the user thread, we have to ask the user to re-type their windows creds (which will be a pain and support burden).

When registering a session for the BFE, it holds the PID, user SID etc. But problem with that is it won’t be able to distinguish the particular user by SID only, e.g. in a terminal services environment you can have multiple people logged in using the same user account, they will have the same SID, but you don’t want messages for one user going to another and vice versa. So you’d really need the window station.

There are some user mode filter layers. But all seem to be related to filtering RPC calls to the BFE. I presume windows sockets doesn’t now all go via RPC via the BFE?

Regards

Adrien

------ Original Message ------
From: “Thomas F. Divine”
To: “Windows System Software Devs Interest List”
Sent: 09/01/2014 11:20:15
Subject: RE: [ntdev] WFP and user-mode

First of all, LSP’s are deprecated starting with Windows 8. That doesn’t necessarily mean that they won’t work, but they are certainly on the way out. There are some HCK tests that explicitly check for “no TDI and no LSP”.

Many WFP callouts include fairly rich meta-data that identifies caller process information, etc. You should be able to invent an I/O scheme that allow your app to inform your WFP driver of its process information, which should allow your WFP driver to know what to do.

PsSetCreateProcessNotifyRoutineEx and friends may also help you in process tracking even without adding an app<->driver communication path.

Should be doable, except for the user interaction. There you would need your application’s help.

No, I haven’t done it, so your mileage may vary…

Good luck!

Thomas F. Divine

http://www.pcausa.com

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Adrien de Croy
Sent: Wednesday, January 8, 2014 4:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WFP and user-mode

Hi all

we’re looking at WFP to replace a current LSP project.

Currently the LSP relies on the fact that it’s loaded in the user context, so has:

* ability to auth using SSPI with our server using current windows user credentials

* ability to pop up a dialog to the user running the winsock app (e.g. login creds dialog, warning, message etc)

The WFP docs state that WFP is intended to allow replacing LSP with WFP apps/drivers/whathaveyou

My question is, is there any way to get access back to the user that is running the application?

I presume from a WFP callout driver in the kernel, you can no longer rely on being in the context of any user thread (e.g. may be in rescheduled kernel worker thread?).

So is there any way to get callouts from user mode? Presumably the ipsec and RPC runtime filters do this, and are registered somehow with the Base Filtering Engine.

Alternatively, if you can rely on being in the user context even only at a not-particularly useful level, could you get say the user window station, and pass that back to some user mode service to push a dialog into that window station?

Or am I stuck with an LSP approach for this?

Thanks in advance.

Adrien

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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