Hello,
It is important for the my file system filter to ‘know’ the user who
has initiated the given IO. For example, my driver allows ‘exceptions’ to
the rules that the driver is enforcing, and these exceptions are simply
account sids. For a given IO, if my file system driver decides its rules
are to be enforced, it checks its list of account ‘exceptions’ against the
user in the current process’s access token (to check for impersonation, it
firsts checks the thread, then the process if the thread turns up empty).
If the user is an account ‘exception’ then the rules are not enforced for
the IO. Note that it does this check in the dispatch routine, so my
assumption was that the driver would always be called in the expected user
context.
Anyways, I’ve begun to notice a problem with shared directories.
For example, when a file is copied into a shared directory from a remote
client, not all of the IO involved in the ‘copy’ occurs with the user who
initiated the copy’s access token. The initial open is performed by a
thread impersonating the user performing the copy operations. However, the
next IO (typically a set eof) occurs in the context of the system process
without impersonation. Therefore, when my file system filter checks its
exception list, it ends up erroneously checking for the presence of the
‘system’ account. So, in the end, even though the user performing the
remote copy is in the exception list, because IO other than CREATE occurs in
the context of the system process (with no impersonation) the file system
filter does not exempt the user from the IOs. Bug.
I fixed this problem by simply caching the SID of the user from the
access token present during the IRP_MJ_CREATE (in a table with FO->SID
records). I remove the entry form the cache during an IRP_MJ_CLOSE. This
seems to have solved the shared directory problem: event if the IO occurs
in the context of the system thread without impersonation, since I always
look to my cache, I always get the correct user.
I was wondering if someone could point me at some documentation on
the parties involved with redirected IO. I’m particularly curious as to how
the server side IO is handled (i.e. the impersonated create, the IO in the
system process context, etc). Also, does the solution to my problem seem
sound? Since I don’t understand precisely what is happening, I cannot be
sure that there are not other special cases that I’ll now run into.
Thanks,
Joel
Dear Smith !
In my opinion the only IRP_MJ_CREATE may directly check the
client context (taken from IrpSp->Parameters.Create.SecurityContext).
If the file is already opened (thus the create/open was successful)
all the next I/O is by definition allowed. One potential problem is
for example: one (trusted) process opens the file and duplicates
the handle to it for another (untrusted) process. I think you can
in addition do the following to solve this: on every successful
IRP_MJ_CREATE save the client SID (associated with File Object)
and on the every next request allow the access only to the thread
with the same user’s SID. Also threads with LOCAL SYSTEM
account should be allowed as those threads are executed only
by trusted (and hope that secured) components.
Paul
-----P?vodn? zpr?va-----
Od: Smith, Joel [SMTP:xxxxx@ntpsoftware.com]
Odesl?no: 15. srpna 2000 20:38
Komu: File Systems Developers
P?edm?t: [ntfsd] context question
Hello,
It is important for the my file system filter to ‘know’ the user
who has initiated the given IO. For example, my driver allows
‘exceptions’ to the rules that the driver is enforcing, and these
exceptions are simply account sids. For a given IO, if my file system
driver decides its rules are to be enforced, it checks its list of account
‘exceptions’ against the user in the current process’s access token (to
check for impersonation, it firsts checks the thread, then the process if
the thread turns up empty). If the user is an account ‘exception’ then
the rules are not enforced for the IO. Note that it does this check in
the dispatch routine, so my assumption was that the driver would always be
called in the expected user context.
Anyways, I’ve begun to notice a problem with shared directories.
For example, when a file is copied into a shared directory from a remote
client, not all of the IO involved in the ‘copy’ occurs with the user who
initiated the copy’s access token. The initial open is performed by a
thread impersonating the user performing the copy operations. However,
the next IO (typically a set eof) occurs in the context of the system
process without impersonation. Therefore, when my file system filter
checks its exception list, it ends up erroneously checking for the
presence of the ‘system’ account. So, in the end, even though the user
performing the remote copy is in the exception list, because IO other than
CREATE occurs in the context of the system process (with no impersonation)
the file system filter does not exempt the user from the IOs. Bug.
I fixed this problem by simply caching the SID of the user from
the access token present during the IRP_MJ_CREATE (in a table with FO->SID
records). I remove the entry form the cache during an IRP_MJ_CLOSE. This
seems to have solved the shared directory problem: event if the IO occurs
in the context of the system thread without impersonation, since I always
look to my cache, I always get the correct user.
I was wondering if someone could point me at some documentation on
the parties involved with redirected IO. I’m particularly curious as to
how the server side IO is handled (i.e. the impersonated create, the IO in
the system process context, etc). Also, does the solution to my problem
seem sound? Since I don’t understand precisely what is happening, I
cannot be sure that there are not other special cases that I’ll now run
into.
Thanks,
Joel