Hi,
I was around, working on this solution for some time and I am understanding the issues one by one.
The current issue is Memory mapped IO.
Could you please evaluate the solution suggested here:
https://www.apriorit.com/dev-blog/371-file-encryption-driver-development-with-per-process-access-restriction
It is a based on implementing a redirector minifilter and an encryption/decryption FS driver
another not recomended solution is encrypt/decrypt minifilter + user mode hooks for memory mapped IO
I skimmed over the article, so I might have missed some details.
The first part of the article is a common misconception that non-cached IO bypasses cache and cached IO goes into cache. Actually, FSD might have a different view and process non-cached IO via cache or bypass cache for cached IO. Fast IO also has no requirement to use cache.
The second part of the article that discusses a separate file system driver implementation has more credibility. Actually, the separate file system is the only known correct solution for data modification. The idea is similar to OSR DMK which is discussed in a series of articles “The Isolation Driver” at this site. Redirection is not required for isolation file system filter, the separate views might be provided by mapping the same path to different data streams depending on credentials in IRP_MJ_CREATE.
Now my thoughts on some problems the author tried to solve. The problem of cache sharing should not exist in a system with correctly designed access check. To map a file for RW(read/write) access a file handle with RW access is required. What is the point to allow open file for RW for a process that is not allowed to read/write the file? Security should be checked when IRP_MJ_CREATE is processed but not when a process reads/writes data.
If a process can duplicate a handle for a file or a section from another process it can compromise the security as well.
So to protect data the security should be checked in IRP_MJ_CREATE and Process Open callback registered with ObRegisterCallbacks .
Hi Slava,
I am just a bit curious what exactly do you mean when you are saying
I am just saying, the way it is written you would think that you see an IRP with IRP_NOCACHE set ( non-cached IO ) the FSD will end-up being serving it from the cache manager’s buffers. Is this what you are implying or some other kind of scenario ?
This second scenario is something that is probably something that happens quite often and it is a bit clearer I guess or should I say I can see it happen.
Hi Gabriel,
Exactly. This is what NTFS does for compressed and encrypted files. File cache is used as intermediate buffer for uncompressed or decrypted data.
OK this is different, but not really and I guess it is done for performance
reasons ( not to read/decrypt or read/uncompress all the time ). This I
guess is something that NTFS, because of this feature has internally
implemented this way.
In this case the Cc Buffer == DISK ( for perf reasons ).
I mean I am sure that in a scenario where, if you open a
compressed/encrypted without NO_CACHE ( and RW on that and build some cache
) and then open a file with NO_CACHE and do read/writes as well, the data
would end-up pbably on the
Cc manager’s buffer assigned for that stream ( for perf. reasons ) and as
soon as there are no refs for any of the FOs it will flush encryp/compress
everything to disk. But the behavior that the UM component or filter
experiences is the same as if the file was neither compressed nor encrypted
since in this scenario the buffer is the DISK, right ?
So the problem I had with the quote was that it sounds like the IRP_NOCACHE
flag basically does not really behave as you would intuitively think it
would, and that is, do not interact with the cache when using this flag. In
this scenario you could argue that there is some grey are as far as the
FSD+Cc is concerned but behavior as seen from other components is the same.
I am waiting to stand corrected now 
Gabriel.
www.kasardia.com
On Tue, Oct 11, 2016 at 4:08 PM, wrote:
> Hi Gabriel,
>
>
>
> Exactly. This is what NTFS does for compressed and encrypted files. File
> cache is used as intermediate buffer for uncompressed or decrypted data.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
Bercea. G.</http:>
The point is that the underlying FSD is not required to honor the FO_NO_INTERMEDIATE_BUFFERING or IRP_NOCACHE if it does not meet the file system’s needs or requirements. From a correctness perspective, all that is really required is write-through behavior.
In my experience the real issue is when people try to do this on top of the network, where the caching behavior changes dynamically based upon the state of communications between the client and the server.
Tony
OSR
>The point is that the underlying FSD is not required to honor the
FO_NO_INTERMEDIATE_BUFFERING
It seems like there ought to be a way to force it to honor
FO_NO_INTERMEDIATE_BUFFERING if only so that the test group at Microsoft
can verify that a particular test is taking a code path that they want to
test. To be clear, I’m absolutely positive that Tony and the others are
correct and that it is not required to honor any particular flag. I’m just
sort of intrigued to think about the testing problem that this approach
creates and i wonder how they solve that problem.
On Tue, Oct 11, 2016 at 9:59 AM, Tony Mason wrote:
>
>
> The point is that the underlying FSD is not required to honor the
> FO_NO_INTERMEDIATE_BUFFERING or IRP_NOCACHE if it does not meet the file
> system’s needs or requirements. From a correctness perspective, all that
> is really required is write-through behavior.
>
> In my experience the real issue is when people try to do this on top of
> the network, where the caching behavior changes dynamically based upon the
> state of communications between the client and the server.
>
> Tony
> OSR
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>