EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Security Violation when CallAllOpenCloseCallbacks set to FALSE

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#7651
Posted: 09/18/2008 18:48:01
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

We would like to have the performance benfits of using SetCallAllOpenCloseCallbacks to FALSE, but we feel that it is a security violation if the file is initially opened in one security context and then later used in another security context. So what we would like would be an open callback for each security context, rather than just one per file.

We think this is a bug because it is possible that the first open is being done by a user with correct access permissions and then subsequent opens might be from unauthorized users.
#7653
Posted: 09/19/2008 00:48:03
by Eugene Mayevski (EldoS Corp.)

There's no bug here, but a design decision. If you want complete control over operations and security, set SetCallAllOpenCloseCallbacks to true.

Personal opinion:
Frankly speaking, you are wasting time trying to set SetCallAllOpenCloseCallbacks to false and try to fool the system and yourself. This won't work for you no matter what else you try. Just set SetCallAllOpenCloseCallbacks to true and forget about this problem. I have described you already how to speed up handling of file open/close operations using counters in your code.


Sincerely yours
Eugene Mayevski
#7662
Posted: 09/19/2008 13:05:33
by Constantin Scheder (Basic support level)
Joined: 09/19/2008
Posts: 3

Eugene: I don't want to be argumentative but this IS a bug. How can you say that it is alright that different security contexts can use the file descriptors from each other? User 1 opens a file and gets handle 1. User 2 just tries a read using handle 1 and it works ??! That is a security violation. File handles CAN NOT and MUST NOT be shared between security contexts.

Constantin Scheder
(Chief Architect, Nirvana division of General Atomics)

PS: this also happens with CallAllOpenCloseCallbacks set to TRUE.
#7663
Posted: 09/19/2008 13:30:06
by Eugene Mayevski (EldoS Corp.)

Quote
Constantin Scheder wrote:
File handles CAN NOT and MUST NOT be shared between security contexts.


Who said that? Most developers don't care about security and they provide file access to any requestor. So they can use a short and quick form of handling file open requests by setting CallAllOpenCloseCallbacks to false. If you need complete control, set CallAllOpenCloseCallbacks to true and validate permissions and access rights in the callback handlers. The documentation has been updated to describe the procedure (in brief) in build 39 which is currently on the site. Online documentation will be updated as well within minutes.

Quote
Constantin Scheder wrote:
PS: this also happens with CallAllOpenCloseCallbacks set to TRUE.


This statement is not clear for me. What "this" happens for you when CallAllOpenCloseCallbacks is set to true?


Sincerely yours
Eugene Mayevski
#7664
Posted: 09/19/2008 13:42:42
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

The "this" that Constantin is referring to is the retaining of the CbFs File Handle Context across opens from different users. In other words, if User one opens a file and our code places something into the Cbfs File Handle Context at that point, we expected that if User two then opened the same file, with SetCallAllOpenCloseCallbacks True, that the File Open callback would be called with a NULL File Handle Context and it isn't. We get the same File Handle Context for user two that was set up by user one.
#7665
Posted: 09/19/2008 13:54:02
by Eugene Mayevski (EldoS Corp.)

Understood. I will talk to Vladimir and someone of us will answer.


Sincerely yours
Eugene Mayevski
#7667
Posted: 09/19/2008 14:12:36
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Also, there is something going on here that Constantin was not aware of until after he sent you his message, which is I implemented an idea that you gave me about using different CbFs objects for different views of our Virtual Drive. Well, in doing that I may be confusing the callbacks because I use the same callback functions for the different objects. It may be that the whole solution to our problem is for me to create a new CbFs object not only for each drive letter that I am using but also for each user that is using it. That way there is no more confusion about security contexts or anything else because the callbacks would get the right information from the correct CbFs object.

This probably sounds a little confusing to you, but I am going to work on it a bit more and let you know what I find out. Meanwhile anything you get from Vladimir or you can think of on your own about this would be appreciated.
#7668
Posted: 09/19/2008 14:19:56
by Eugene Mayevski (EldoS Corp.)

This is not confusing at all. Moreover, we already recomended to some user to use different CallbackFileSystem objects and to create different mounting points for each user session.


Sincerely yours
Eugene Mayevski
#7669
Posted: 09/19/2008 14:32:15
by Eugene Mayevski (EldoS Corp.)

Now about your and Constantin's question about security.
The value of UserContext belongs to a file system object (FSO) in kernel. This means that all open/close operations on a file (from first open till last close) share the context. However, this is not really a problem. And here's why.

As we mentioned several times, security checks should occur *only* in OnOpenFile/OnCreateFile callback handlers (and some supplementary callbacks which such as enumeration ones but we will omit them for simplicity). The handler should either open the logical file (for which the request was issued) or deny access. After that the requested read/write operations should be performed.

Let's consider the following scenario:

1) User A requests read/write access to the file. You grant it and the OS gets handle X.
2) User B requests read-only access to the same file and he has no rights to write to this file. You grant access and the OS gets handle Y.

Two file open operations share the same context. But this is context used by your application (not by the OS). The OS operates handles X and Y. And the OS knows that handle X has read/write access and handle Y has read-only access. It won't issue write request for handle Y. If this is what you worry about.

Now about storing your information in the context. Yes, if you open the file (for example in remote storage) separately for request 1 and request 2, then you have a programming problem to solve. I won't go into details, but there's no easy way to introduce a separate context for requests 1 and 2, so we have to live with one context per file.


Sincerely yours
Eugene Mayevski
#7670
Posted: 09/19/2008 15:20:48
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

What would happen if in request 2 we overwrite the File Handle Context with a new one? Does a subsequent write then get the new File Handle Context?

The File Handle Context in the Open call back is passed in as *PVOID, implying that we can change it and the change is reflected back in your code. In the Read and Write call backs it is passed in as PVOID, implying that it cannot be changed there. Am I correct in this analysis or is there something more to it that I don't understand?
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 7258 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!