I have a filter that needs to open a handle to a file, but I want to make sure that if the security for a particular user changes that this propogated.
For example, a user opens a file and the PostCreate succeeeds. If I need to do something with that file later on, I want to make sure that that particular use still has access to do so.
I know that in the callback data in pre/post create I have a security context object, how can I resuse that with FltCreateFile? Is that possible?
>I know that in the callback data in pre/post create I have a security
context object, how can I resuse that with >FltCreateFile? Is that
possible?
The way you do this is through impersonation. So, you capture the
credentials of the caller (e.g. SeCaptureSubjectContext,
SeCreateClientSecurityFromSubjectContext) and then you can impersonate the
caller with SeImpersonateClientEx. Subsequent creates with the
IO_FORCE_ACCESS_CHECK bit set will then be validated using the user’s
security credentials.
You could also create a kernel thread that runs in a process context with
the credentials you want (see PsCreateSystemThread’s ProcessHandle
parameter) and send all of your creates from there (again specifying the
force access check option).
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntfsd…
> I have a filter that needs to open a handle to a file, but I want to make
> sure that if the security for a particular user changes that this
> propogated.
>
> For example, a user opens a file and the PostCreate succeeeds. If I need
> to do something with that file later on, I want to make sure that that
> particular use still has access to do so.
>
> I know that in the callback data in pre/post create I have a security
> context object, how can I resuse that with FltCreateFile? Is that
> possible?
>
AFAIK, just knowing the user won’t help you, you need to know the whole
security context, so you can use SeCreateClientSecurityFromSubjectContext
for that. Also, the security context is captured by IO manager so you can’t
pass it in as a parameter. What you can do is impersonate the user, issue
your create to check whether the user still has access to the file, and then
revert the impersonation.
I’ve done something like this:
SeLockSubjectContext( context );
…
SeCreateClientSecurityFromSubjectContext( context, …,
myCopyOfTheContext);
SeUnlockSubjectContext( subjectContext );
And then, later on when you need to access the file as that user,
SeImpersonateClientEx(myCopyOfTheContext, …);
ZwCreateFile(…);
SeStopImpersonatingClient();
Hopefully this will work, but you should definitely try for yourself, I use
the code above for an entirely different purpose so perhaps it’s not what
you need…
Thanks,
Alex.
> ZwCreateFile(…);
SeStopImpersonatingClient();
Hopefully this will work, but you should definitely try for yourself, I
use
the code above for an entirely different purpose so perhaps it’s not what
you need…
The only thing that I’ll note here is that calling ZwCreateFile will bypass
the security check on the open for local access (your requestor mode will be
kernel so SeAccessCheck will just say, “OK”). Calling
IoCreateFile/FltCreateFile allows you to specify IO_FORCE_ACCESS_CHECK,
which gets propagated into the I/O stack location flags and causes NTFS to
call SeAccessCheck with a requestor mode of user.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Alex Carp” wrote in message
news:xxxxx@ntfsd…
> AFAIK, just knowing the user won’t help you, you need to know the whole
> security context, so you can use SeCreateClientSecurityFromSubjectContext
> for that. Also, the security context is captured by IO manager so you
> can’t
> pass it in as a parameter. What you can do is impersonate the user, issue
> your create to check whether the user still has access to the file, and
> then
> revert the impersonation.
>
> I’ve done something like this:
> SeLockSubjectContext( context );
> …
> SeCreateClientSecurityFromSubjectContext( context, …,
> myCopyOfTheContext);
> SeUnlockSubjectContext( subjectContext );
>
> And then, later on when you need to access the file as that user,
>
> SeImpersonateClientEx(myCopyOfTheContext, …);
> ZwCreateFile(…);
> SeStopImpersonatingClient();
>
> Hopefully this will work, but you should definitely try for yourself, I
> use
> the code above for an entirely different purpose so perhaps it’s not what
> you need…
>
> Thanks,
> Alex.
>
>
Thanks for the help as usual guys. I was staring out the docs for so long I was going blind trying to figure this out.