Author: bleny Date: 2010-07-23 17:36:32 +0200 (Fri, 23 Jul 2010) New Revision: 110 Url: http://nuiton.org/repositories/revision/diswork/110 Log: doc secu dans diswork FS Modified: trunk/src/site/rst/diswork-fs/devel.rst Modified: trunk/src/site/rst/diswork-fs/devel.rst =================================================================== --- trunk/src/site/rst/diswork-fs/devel.rst 2010-07-23 13:22:40 UTC (rev 109) +++ trunk/src/site/rst/diswork-fs/devel.rst 2010-07-23 15:36:32 UTC (rev 110) @@ -3,14 +3,14 @@ ============================= Abstract --------- +======== This document is for people who want to develop Diswork File System. It is not an interesting reading for people who write to write code that use Diswork FS. Diswork File System uses a map to store every data --------------------------------------------------- +================================================== Diswork File System uses a map to store data persistently. @@ -138,11 +138,74 @@ The map is distributed ---------------------- -The map described above is distributed over all nodes through a DHT. +The map described above is distributed over all nodes through a DHT. Diswork File System manage concurrency -------------------------------------- DFS uses copy-on-write to deal with concurrency. Nothing is overridden, when a file is replaced, the new file is written on the FS without removing the -old file. The old file data is kept and actually removed later. \ No newline at end of file +old file. The old file data is kept and actually removed later. + +User rights management and security issues +========================================== + +Peer-to-peer applications are subject to malicious attacks. Introduction of one +or few malicious node in such a network can cause many problems. + +At the File System level, since there is no user-rights management, a malicious +node can connect and remove recursively root directory or replace any file +with any bits. + +At the DHT level, any malicious node introduce multiple threats : + +* a distributed denial of service attack (multiple nodes always asking for the + same key) + +* various DHT-specific attacks like joining the DHT with a chosen ID allowing + to become responsible of a target key that will no longer be avaible due to + a malicious peer that do not respond. + +* low-level attacks : by sniffing network traffic, key and values that pass + through the target connection may be revealed and data privacy corrupted + +DHT implementation may provides means to prevent DHT-level threats but we still +need some ways to prevent File-System level threads. The main problems here is +that DHT is readable/writable shared memory for each of the nodes connected to +the network. Thus, a single node can write any bad data. + +Those issues lead to the need to implements consider user-rights on the +File-System. This is not possible because all nodes are self-responsible to +what they do on the DHT. Thus, the nodes that do the operation on the DHT will +will be responsible to check it has the right to do so. It's easy to imagine +a malicious node, allowing itself all operations by badly implementing rights +checks. + +To make user-rights management possible, DHT should give make all operation +of a node controlled by another one. Just like a given program, running in +an operating system, can't do any I/O on local file system, the underlying +file-system is another piece of code that manage the program rights. Here, +we don't have this intermediate code, so another node should do this job and +system will become reliable if it's not possible for a malicious node to choose +itself as intermediate node or any node cooperating with the malicious one. + +However, this is a DHT consideration and we can't deal with malicious nodes +at the File System level. + +But we can provide a security layer on top of the file-system. This layer +should permit to crypt and sign data one writes in order for others to check +data integrity. Those operations can be done using asymetric key encryption. + +When reading/writing a file or directory, keys will permit to be sure that +a given file or directory content has been written by a given user. + +That's not sufficient, malicious nodes can crypt and sign datas too. So +top level application, that use the File system should make is own +business-oriented checks before considering a data. + +Nodes can write and then read encrypted data if it checks the +file integrity. Public keys should not be made available through Diswork FS +since it can be replaced by a malicious node. + +Public keys for each nodes should be made available by another means. It may +be a read-only public key store available through HTTP for example. \ No newline at end of file