EldoS | Feel safer!

Software components for data protection, secure storage and transfer

filtering content based on process (problem with UserContext shared)

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#23983
Posted: 03/07/2013 15:21:50
by James FitzGerald (Priority Standard support level)
Joined: 02/27/2013
Posts: 4

I am attempting to create a solution that provides encoded content to certain processes and decoded content to others.
In the PostOpenC/PostCreateC callbacks I check the process name and stash that information in the context.
Problem is this context is being used by more than one process where I see it come back in by a call to PostOpenC but from a different process.

How will I be able to identify the true process in the read or write calls if different processes can use the same context information for a given file?
#23985
Posted: 03/07/2013 15:54:18
by Vladimir Cherniga (EldoS Corp.)

GetOriginator*** methods obtain information that is saved during file stream opening. When you use these functions in Read/Write callbacks they returns the information preserved during open request and associated with a file handle in user mode.
#23992
Posted: 03/08/2013 01:14:00
by Eugene Mayevski (EldoS Corp.)

The problem is that the OS was not designed to support your idea. When the data is read or written, it's kept in the cache and combined there. The application reads and writes data from/to the cache. And different application, if they were allowed to open the file, should be able to see the same data.

The OS provides partial workarounds within their volume snapshot service and when the file is opened for backup (there the OS needs to solve the same problem - let the application copy the encrypted data without decrypting it). But these workarounds are available explicitly via Win32 API and not available for fine-grain control from CallbackFilter.

By default what you intercept with CallbackFilter is the request going from the cache to the filesystem.

While it's possible (with CallbackFilter) to catch the operations when the request goes from the requester to the cache (and not to the FS), thus bypassing the above complexity, CallbackFilter doesn't distinguish system requests to the cache and application requests to the cache, and it's not clear whether such separation is possible.

To put it simple, if we had time and resources, we could check this assumption and maybe (!) implement what you need, but at the moment this is not possible.


Sincerely yours
Eugene Mayevski
#24001
Posted: 03/08/2013 09:38:57
by James FitzGerald (Priority Standard support level)
Joined: 02/27/2013
Posts: 4

What really threw me was the documentation for the GetOriginator*** calls. It states this:

" Do not call this method from handlers for OnReadFile*, OnWriteFile* and other callbacks that work with opened files, as that callbacks can be initiated by the system components (cache manager, memory manager etc.). Instead do the following:

Call GetOriginatorProcessName from OnCreateFile or OnOpenFile event handlers / callbacks;
Store obtained information somewhere and store the reference to this information in the UserContext;
When you need to check the originator information in some file-related callback, access the stored information via UserContext
"

But that isn't useful when different originating processes can work with the same context. Not following the approach recommended by the documentation and instead calling getOriginator explicitly in the onRead/Write calls seems to work okay.

I will test it some more.

Thanks for the prompt replies!
#24002
Posted: 03/08/2013 09:44:54
by Eugene Mayevski (EldoS Corp.)

Classic case of GIGO (garbage in, garbage out). Calling GetOriginator*** from OnRead/OnWrite will work but it will return the cached value (!). It won't give you what you want, and what you want is plain NOT POSSIBLE.


Sincerely yours
Eugene Mayevski
#24019
Posted: 03/11/2013 09:01:40
by Manoj Jain (Standard support level)
Joined: 02/28/2013
Posts: 94

Quote
I am attempting to create a solution that provides encoded content to certain processes and decoded content to others.


I am also trying to do the same.

The requirement is that the encrypted file [say .jpg] should be opened by only one program say "MS paint" and not by any other say Adobe Photoshop or others.

Currently using encryption sample, all programs can open.

If it is possible by win32 API please give some leads on which we can work.

Thanks
#24020
Posted: 03/11/2013 10:03:10
by Eugene Mayevski (EldoS Corp.)

Let me repeat it once again - it is NOT possible to "create a solution that provides encoded content to certain processes and decoded content to others".

The best you can do is check the process that requests file open/file create and deny the request if this is not the intended process.


Sincerely yours
Eugene Mayevski
#24024
Posted: 03/11/2013 23:23:45
by Manoj Jain (Standard support level)
Joined: 02/28/2013
Posts: 94

Quote
The best you can do is check the process that requests file open/file create and deny the request if this is not the intended process.


This is great. This will solve my problem.

Please guide me through. If possible a little detail. I am using encryption sample in c#.
#24025
Posted: 03/12/2013 00:34:45
by Manoj Jain (Standard support level)
Joined: 02/28/2013
Posts: 94

Code
  string OriginatorProcess2;


        mFilter.GetOriginatorProcessName(out OriginatorProcess2);

        AddToLog(string.Format("Open by", OriginatorProcess2));



        if (OriginatorProcess2.StartsWith("Adobe"))
             {

                 ProcessRequest = true;
             }
  
        else{
                  ProcessRequest = false;
             }



With above code I am not getting process name. It is empty in log. and hence file is not running [permission denied as per code above]

So question is how to get originator process name.
#24028
Posted: 03/12/2013 00:53:57
by Eugene Mayevski (EldoS Corp.)

Where exactly are you calling the code above? I.e. are you calling it in the OnOpenFileC event handler (this is the only place where it makes sense)?


Sincerely yours
Eugene Mayevski
Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.

Reply

Statistics

Topic viewed 7001 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!