I’ve a need to distinguish whether file I/O (on a local volume) is a
result of local or remote access.
I see in the archives that there is not certain way to do this, and
that the best bet is to check, during Create, if one’s running in the
System process and if the calling thread has credentials (meaning it
impersonates a user).
Now, given IrpSp->Parameters.Create.SecurityContext->AccessState
->SubjectSecurityContext.ImpersonationLevel
is its value sufficient to tell if access is local or remote?
From little testing I see that local access has this value set to
SecurityAnonymous, while remote access has SecurityImpersonation.
I’m probably not right, but it’s very well worth asking!
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
You need unambigouosly define what do you consider as a remote access.
For example services for UNIX doesn’t use impersonation, but use some
predefined account to access files.
On the other hand in cleint-server environment server thread may be
impersonated.
Are you actually trying to detect if request was originated via standard NT
share from remote computer?
Or you trying to detect if request was originated through share from local
or remote computer?
In later case I am not sure that ImpersonationLevel is reliable if request
comes from the same computer.
Alexei.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
>
> I’ve a need to distinguish whether file I/O (on a local volume) is a
> result of local or remote access.
> I see in the archives that there is not certain way to do this, and
> that the best bet is to check, during Create, if one’s running in the
> System process and if the calling thread has credentials (meaning it
> impersonates a user).
> Now, given IrpSp->Parameters.Create.SecurityContext->AccessState
> ->SubjectSecurityContext.ImpersonationLevel
> is its value sufficient to tell if access is local or remote?
> From little testing I see that local access has this value set to
> SecurityAnonymous, while remote access has SecurityImpersonation.
> I’m probably not right, but it’s very well worth asking!
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
> developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
>
I’d prefer just to tell if it’s coming from a remote computer.
Better yet, I’m trying to find this during read/write, so I thought of
noting it during create.
The problem with checking during IRP_MJ_CREATE is that you can only flag
that File object to know it’s used for remote access - but there’s no guarantee
that that FO will be used during read/write…
In fact, after a small test, I see that it won’t be… so even if I flag it
during create, it won’t be sufficient.
Scratch one…
I’m sure this can be done, because I’ve seen it done…
Alexei Jelvis wrote:
You need unambigouosly define what do you consider as a remote access.
For example services for UNIX doesn’t use impersonation, but use some
predefined account to access files.
On the other hand in cleint-server environment server thread may be
impersonated.
Are you actually trying to detect if request was originated via standard NT
share from remote computer?
Or you trying to detect if request was originated through share from local
or remote computer?
In later case I am not sure that ImpersonationLevel is reliable if request
comes from the same computer.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Do you see using different FO for paging IO?
Actually there is not no way unambigouosly associate paging IO to a handle.
Alexei.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
>
> I’d prefer just to tell if it’s coming from a remote computer.
> Better yet, I’m trying to find this during read/write, so I thought of
> noting it during create.
> The problem with checking during IRP_MJ_CREATE is that you can only
flag
> that File object to know it’s used for remote access - but there’s no
guarantee
> that that FO will be used during read/write…
> In fact, after a small test, I see that it won’t be… so even if I
flag it
> during create, it won’t be sufficient.
> Scratch one…
>
> I’m sure this can be done, because I’ve seen it done…
>
> Alexei Jelvis wrote:
>
> > You need unambigouosly define what do you consider as a remote access.
> > For example services for UNIX doesn’t use impersonation, but use some
> > predefined account to access files.
> > On the other hand in cleint-server environment server thread may be
> > impersonated.
> > Are you actually trying to detect if request was originated via standard
NT
> > share from remote computer?
> > Or you trying to detect if request was originated through share from
local
> > or remote computer?
> > In later case I am not sure that ImpersonationLevel is reliable if
request
> > comes from the same computer.
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
>
> Do you see using different FO for paging IO?
No - I had a bug in the code (forgot break in case statement).
I’m sure the above can happen though.
Actually there is not no way unambigouosly associate paging IO to a handle.
Meaning what?
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
He means that the paging I/O may be sent down with a temporary stream
file object or the cache manager’s captive file object for the file
instead of the original file object associated with the user handle. You
know it’s the same file because the FsContext is the same, but that’s
about it.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Saturday, April 05, 2003 4:24 PM
To: File Systems Developers
Subject: [ntfsd] Re: SECURITY_IMPERSONATION_LEVEL
> Do you see using different FO for paging IO?
No - I had a bug in the code (forgot break in case statement).
I’m sure the above can happen though.
> Actually there is not no way unambigouosly associate paging IO to a
> handle.
Meaning what?
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption
services. Alfa File Protector - File protection and hiding
library for Win32 developers. Alfa File Monitor - File
monitoring library for Win32 developers.
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Paging I/O with a different FO is fine with my requirements - it’s
normal I/O that I want to see with the original FO.
Nicholas Ryan wrote:
He means that the paging I/O may be sent down with a temporary stream file
object or the cache manager’s captive file object for the file
instead of the original file object associated with the user handle. You
know it’s the same file because the FsContext is the same, but that’s
about it.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Well… I don’t see how this can be the case with ‘normal’ I/O unless
you’ve got some kind of weird third-party filter on the system mirroring
file opens or some such. If user thread A opens file handle B, file
handle B refers to file object C, and all top-level I/O generated by
thread A on handle B will be seen by your filter with file object C.
I think that stream file objects are created and used by some entities
for more than just paging I/O. I’m too lazy to check right now but at
least one reference document recommends checking for new stream file
objects on all entry points (which I do on my filter). Perhaps this is
what you’re seeing - can you check the FO_STREAM_FILE flag?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Saturday, April 05, 2003 5:29 PM
To: File Systems Developers
Subject: [ntfsd] Re: SECURITY_IMPERSONATION_LEVEL
Paging I/O with a different FO is fine with my
requirements - it’s normal I/O that I want to see with the
original FO.
Nicholas Ryan wrote:
> He means that the paging I/O may be sent down with a
temporary stream
> file object or the cache manager’s captive file object for the file
> instead of the original file object associated with the
user handle.
> You know it’s the same file because the FsContext is the same, but
> that’s about it.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption
services. Alfa File Protector - File protection and hiding
library for Win32 developers. Alfa File Monitor - File
monitoring library for Win32 developers.
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I mentioned I was missing a break in case statement, so I do see only
the original FO. I didn’t do too much testing, to see if I do get any other
FO for normal I/O…
Nicholas Ryan wrote:
Well… I don’t see how this can be the case with ‘normal’ I/O unless
you’ve got some kind of weird third-party filter on the system mirroring
file opens or some such. If user thread A opens file handle B, file
handle B refers to file object C, and all top-level I/O generated by
thread A on handle B will be seen by your filter with file object C.
I think that stream file objects are created and used by some entities
for more than just paging I/O. I’m too lazy to check right now but at
least one reference document recommends checking for new stream file
objects on all entry points (which I do on my filter). Perhaps this is
what you’re seeing - can you check the FO_STREAM_FILE flag?
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
> Sent: Saturday, April 05, 2003 5:29 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: SECURITY_IMPERSONATION_LEVEL
>
>
>
> Paging I/O with a different FO is fine with my
> requirements - it’s normal I/O that I want to see with the
> original FO.
>
> Nicholas Ryan wrote:
>
> > He means that the paging I/O may be sent down with a
> temporary stream
> > file object or the cache manager’s captive file object for the file
> > instead of the original file object associated with the
> user handle.
> > You know it’s the same file because the FsContext is the same, but
> > that’s about it.
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption
> services. Alfa File Protector - File protection and hiding
> library for Win32 developers. Alfa File Monitor - File
> monitoring library for Win32 developers.
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
If you don’t want to consider files accessed via services for UNIX, services
for MAC and other components that work on behalf of remote user as a remote
access, you can check source of the impersonation token
(SeQueryInformationToken with TokenInformationClass set to TokenSource) of
the calling thread in addition to checking that it is the system processs.
This way you will know that the thread was impersonated by SRV, not by some
other component.
I believe that you can check only at create time, during read/write
operations you will not have appropriate context to validate.
Alexei.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
>
> I’ve a need to distinguish whether file I/O (on a local volume) is a
> result of local or remote access.
> I see in the archives that there is not certain way to do this, and
> that the best bet is to check, during Create, if one’s running in the
> System process and if the calling thread has credentials (meaning it
> impersonates a user).
> Now, given IrpSp->Parameters.Create.SecurityContext->AccessState
> ->SubjectSecurityContext.ImpersonationLevel
> is its value sufficient to tell if access is local or remote?
> From little testing I see that local access has this value set to
> SecurityAnonymous, while remote access has SecurityImpersonation.
> I’m probably not right, but it’s very well worth asking!
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
> developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
>
> If you don’t want to consider files accessed via services for UNIX, services
for MAC and other components that work on behalf of remote user as a remote
access
What happens in this case? (i.e. if I do want to consider them)
This way you will know that the thread was impersonated by SRV, not by some
other component.
I believe that you can check only at create time, during read/write
operations you will not have appropriate context to validate.
Yes, this is certain.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
> you can check source of the impersonation token
(SeQueryInformationToken with TokenInformationClass set to TokenSource) of the
calling thread in addition to checking that it is the system processs.
I assume this means SeQueryInformationToken on
PsReferenceImpersonationToken return value (what to use as the thread?,
Irp->Tail.Overlay.Thread?)?
What should the token source be for SRV? (can this technique be used to
tell Services for MAC/Unix?)
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> > If you don’t want to consider files accessed via services for UNIX,
services
> > for MAC and other components that work on behalf of remote user as a
remote
> > access
>
> What happens in this case? (i.e. if I do want to consider them)
I afraid there is no general solution to the problem. As far as file system
is concerned those services are just local components. They don’t explicitly
expose the fact that they are working on behalf of a remote user. For
example services for UNIX perform IO in the context of some specific local
user. I believe (although not 100% sure) that it is implemented in user mode
as a service so checking if it is the system process will fail.
There are several implementations of services for MAC that behave in
different ways.
Most of such services don’t create mapping between users on another
operaring system and Windows NT users so no impersonation is taken place.
So I afraid that there is no better solution than explicitly decide what
programs are to be considered as working on behalf remote user. Then you can
query context in some specific way to check request was originated from one
of those programs.
Basically you have no way detect if the program that accesses the file is
controlled from remote computer or what the programm is going to do with the
data it read. The best you can do is make a guess based on the behavoiur of
the programm and on the security context.
Alexei.
One stupid question - how do I check if it’s the system process, aside from
name matching?
in addition to checking that it is the system processs.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
>
> One stupid question - how do I check if it’s the system process, aside
from
> name matching?
>
When you are in DriverEntry or executing WorkItem you are garanteed to be in
the system process. Just remember result of PsGetCurrentProcess in such
context and compare it with the result of PsGetCurrentProcess in current
context.
Alexei.
> > in addition to checking that it is the system processs.
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
>
>
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> > you can check source of the impersonation token
> > (SeQueryInformationToken with TokenInformationClass set to TokenSource)
of the
> > calling thread in addition to checking that it is the system processs.
>
> I assume this means SeQueryInformationToken on
> PsReferenceImpersonationToken return value (what to use as the thread?,
> Irp->Tail.Overlay.Thread?)?
Yes, that is what I meant.
> What should the token source be for SRV?
SourceName is NtLmSsp
> (can this technique be used to tell Services for MAC/Unix?)
Actually I am not sure, but I afraid it can’t be used. As far as I know
services for UNIX do not impersonate remote user, so TokenSource is
irrelevant.
Alexei.
>
> –
> Kind regards, Dejan M. MVP for DDK
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
>
Hmm… I was using IoGetCurrentProces in DriverEntry (which in NT DDK at
least is the same as PsGetCurrentProcess), and IoGetRequestorProcess(Irp), which
didn’t yield the right results.
I’ll try this.
When you are in DriverEntry or executing WorkItem you are garanteed to be in
the system process. Just remember result of PsGetCurrentProcess in such
context and compare it with the result of PsGetCurrentProcess in current
context.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
>Hmm… I was using IoGetCurrentProces in DriverEntry (which in NT DDK at
least is the same as PsGetCurrentProcess), and
IoGetRequestorProcess(Irp), which
didn’t yield the right results.
I’ll try this.
It is strange, IoGetRequestorProcess should work properly.
Alexei.
I thought so, too, but it didn’t. PsXXX worked. Thanks.
It is strange, IoGetRequestorProcess should work properly.
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.