Impersonation

Hi,

In my minifilter’s PreCreate routine, I have to call FltCreateFileEx. The thread that originated the request may be impersonating and I need FltCreateFileEx to use the same token.

On my experience (may be my tests to be wrong), I had to (re?-)impersonate using SeCreateClientSecurityFromSubjectContext but it fails if thread token is identification.

Can anyone tell me if impersonation is lost in the inner call to FltCreateFile?

Regards,
Mauro.

> Can anyone tell me if impersonation is lost in the inner call to

FltCreateFile?

Not sure that I can confirm or deny, but I always make sure that the
SecurityDescriptor is set in InitializeObjectAttributes and that seems to do
the thing.

Hi Rod,

Yes, the SD is set properly but based on my experience I have to call to SeCreateClientSecurityFromSubjectContext.

But having problems when thread is using an identification token because the call to SeCreateClientSecurityFromSubjectContext fails (as expected). No idea if there exists another approach.

What behavior are you seeing that makes you think you need to impersonate?

Also, are you setting the IO_FORCE_ACCESS_CHECK bit in your FltCreateFile
call?

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Hi Rod,

Yes, the SD is set properly but based on my experience I have to call to
SeCreateClientSecurityFromSubjectContext.

But having problems when thread is using an identification token because the
call to SeCreateClientSecurityFromSubjectContext fails (as expected). No
idea if there exists another approach.

Hi Scott, sorry for the late answer (little illness)

I’m not using the IO_FORCE_ACCESS_CHECK flag. Basically I’m redirecting a folder to another location.

Sometimes I see a worker thread that is not impersonating but the Data->Iopb->Parameters.Create.SecurityContext has the Client and Primary tokens.

Other times I see a thread impersonating and SecurityContext with same info.

In any case I need to pass that info to my FltCreateFileEx so I use SeCreateClientSecurityFromSubjectContext but fails, as expected, if the client token is an identification one.

Want to know if there exist some alternative.

Kind regards,
Mauro.

If you’re not setting IO_FORCE_ACCESS_CHECK then the request is being
treated as a kernel mode call, so the security context doesn’t really
matter.

However, two other questions:

  1. What’s the RequestorMode of the request that’s coming in with a
    SecurityContext->ClientToken != NULL?

  2. What’s the call stack for the thread? You said it’s a worker thread. Did
    someone post an IRP_MJ_CREATE to this thread so that it could be handled
    asynchronously? Or is the create originating from this thread?

-scott
OSR
@OSRDrivers

“%%merge inmail_.HdrFrom_%%” wrote in message news:xxxxx@ntfsd…

Hi Scott, sorry for the late answer (little illness)

I’m not using the IO_FORCE_ACCESS_CHECK flag. Basically I’m redirecting a
folder to another location.

Sometimes I see a worker thread that is not impersonating but the
Data->Iopb->Parameters.Create.SecurityContext has the Client and Primary
tokens.

Other times I see a thread impersonating and SecurityContext with same info.

In any case I need to pass that info to my FltCreateFileEx so I use
SeCreateClientSecurityFromSubjectContext but fails, as expected, if the
client token is an identification one.

Want to know if there exist some alternative.

Kind regards,
Mauro.

Hi Scott, I could track the problem deeper and it is not related to filtering but this:

http://www.osronline.com/showthread.cfm?link=285998

Thank you,
Mauro.