RegisterSign In
By Roger De Mestaul (rogerd) on Feb 7, 2011 1:15 AM.
Hi Tobias,

I've noticed that you haven't any instrument for enforcing security over the network: for example, all that is needed to access is a network password and that's all.
Don't you think that a database of authorized clients and a list of operations allowed should be implemented?

By Tobias Downer (toby) on Feb 7, 2011 3:47 AM.
Hi Roger,

For network level security - The network.conf file (specifically the connect_whitelist property) is used to white-list the IP address of machines on the network so only known machines may connect to the MckoiDDB servers. It is required to define this property otherwise the server will reject all connections. It is assumed that MckoiDDB machine nodes are installed on a controlled and secure network and there is no vector for attack directly on a MckoiDDB TCP port (firewalls and/or private networks can ensure this). Assuming this, the only way to compromise a MckoiDDB database would be through vulnerabilities in the front-end application software on the none private networks.

Or were you asking why there is no access control in the data models? eg. Allowing a policy to be defined so User 'A' may not add records to an 'Employee' table. User/Privilege systems are a little outside the scope of the data models offered in MckoiDDB currently. However, an application side authentication system can be implemented over MckoiDDB. I've actually been doing some work on this for an upcoming project.

By Alfredo Sanchez (alfy) on Feb 12, 2011 6:08 AM.
I find the Roger's point interesting: in fact, the Consensus functions can determine if the data model is respected, but doesn't inform you which client is connected and in most of the cases it is necessary to know who is issuing a command and check if it is authorized.
Naturally, the table with authorizations can be stored into a Consensus implementation, but how can I know if client Bob can issue a Commit, or can retrieve lines from 150 to 230? And many other examples like these (I'm thinking about SQL privileges case).

By Tobias Downer (toby) on Feb 12, 2011 12:45 PM.
To implement a secure system where the MckoiDDB clients can be untrusted would be difficult for a number of reasons. Once a bit of information in a data model reaches the point where it is passed around the nodes of a MckoiDDB network as a block of data, it is difficult for the system to determine what the data actually represents. This isn't such an issue for writes because you could assume a trusted root server and consensus function that has an access control database, and you could put authentication in the commit function. However, reads are another matter entirely. The problem for reads is that data does not get stored with any information about where it originated from, so to determine if a request for a bit of data is allowed would require extensive analysis. To mark up all data with origin information would greatly reduce the flexibility of the block storage system and lead to a lot of replication (eg. you could no longer replicate a file by only copying the meta data because the copied file would need different origin information on its entire content).

So by design, to ensure MckoiDDB is secure the clients must be trusted. With trusted clients it makes it possible (quite easy infact) to build authentication and fine-grained access control in the application server running over a MckoiDDB network. Also another consideration for security that was made in the design is that any damage done by a compromised client is reversible through roll backs.

Please sign in or register to post in this topic.
The text on this page is licensed under the Creative Commons Attribution 3.0 License. Java is a registered trademark of Oracle and/or its affiliates.
Mckoi is Copyright © 2000 - 2017 Diehl and Associates, Inc. All rights reserved.