Re: [Algorythm] Read-write on a shared file
From: Chris F.A. Johnson (cfajohnson_at_gmail.com)
Date: 08/01/04
- Next message: ynotssor: "Re: [Algorythm] Read-write on a shared file"
- Previous message: xm: "[Algorythm] Read-write on a shared file"
- In reply to: xm: "[Algorythm] Read-write on a shared file"
- Next in thread: xm: "Re: [Algorythm] Read-write on a shared file"
- Reply: xm: "Re: [Algorythm] Read-write on a shared file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 1 Aug 2004 07:09:29 GMT
On 2004-08-01, xm wrote:
> Hi there,
> I have a problem that I would like to program a solution for, though
> I'm wondering about the algorythm and I was looking for your comments.
>
> Here's the problem:
> There one file (the file) which is stored on N different computers.
Then it's not the same file; the contents may be the same, but
that's coincidental. There is a different instance of the file on
each computer.
> There is no central host. Only a fraction of those computers have
> read and write permission and the rest only have read permission.
If there's no central host, how is "the file" propagated?
> The file is thus based on each and every computer in this situation.
> And let say the file contains sensitive information that Must not be
> changed by someone that cannot write to it.
If one cannot write to it, one cannot change it.
> Moreover, let say part of that file must be unreadable or encrypted
> to specific individuals.
An entirely different issue.
> Then let say a hacker in in front of one of the computer that only
> have read access. Let say this hacker will try to sniff the
> networking protocol,
What networking protocol? How is the local version of the file
being created?
> that he will try to crash the program and dig into the core dump, or
> possibly will use some tool to look right in memory while the
> program is running.
What program is running? Where?
> Anyhow, he must not read the portions that he's not supposed to and
> he must not commit changes to the file that will change the files on
> the other computers.
If he has read/write access, he can change the file; if not, he
can't. What's the issue?
> Here's my approach: (it might be wrong, this is where you can
> comment aplenty!)
> In the file is written read and write permissions for all users (or
> there may be a separate file for permissions).
If the file should not have read and permissions write for all
users, fix the program that's writing it.
> Some parts of the file will be encrypted with different algorythms
> (or different keys) for the different users or groups that have
> access to those parts.
What's the issue?
> Now, if someone wants to read this file they must understand it's
> format to change the read/write permissions (which is possible
> locally)
If it's possible locally, then you need to fix the read/write
permissions.
> and then read the sections that the hacker wants, but they will be
> encrypted with a key, that will be stored locally on the specific
> computers that are allowed to decrypt these sections. Therefore the
> hacker does not have a key. And sniffing the network to catch one
> being sent from a trusted individual to another is irrelevant
> because all communications will be SSL encrypted.
What's the issue?
> And if the hacker wants to commit changes to the file, he must forge
> himself to appear as being one of the users that have write access in
> that file, then send the change via the program (there will be a
> special protocol for changes) which will contact different hosts and
> negotiate the change.
Now, perhaps, we are getting to the crux of the matter.
If the machine is compromised, you must fix it, otherwise
everything else is irrelevant.
> These other hosts may or may not be compromised (at worst!) and they
> will receive a modification from a certain user (here I'm thinking the
> SSL session could be encrypted using the private key of the sender to
> the public key of the receiver and those keys should corresponds to
> their logins, so how would it be possible to inpersonnate someone else
> without those private keys?). So a computer receives a modification
> from a certain user, this computer checks to see what is the file in
> question, it is an important file which contains data that himself
> cannot read or change, so this computer will deny the change and tell
> the computer to contact this and that computer to make the change.
> Those pointed computers will be the ones with write access, and they
> will look a the change, the user requesting it, the keys and will
> decide if they commit or not the change.
> Now here I am with a 'decide' algorythm to make. But I'm not sure
> what could prove a decision to be good or not.
The only decision that matters is whether to fix the compromised
machines, or stop writing to them.
> Possibly the username(falsified in this example) and the public key
> (it is public, so anyone can have it) plus a communication
> peer-to-peer encrypted with the private key of the sender (which the
> hacker cannot get) and the public key of the receiver.
> In other words, for authentication over this network, only the
> peer-to-peer encrypted handshake could serve the purpose? Or maybe
> that is not enough.
>
> Thanks for any comments!
> xm
--
Chris F.A. Johnson http://cfaj.freeshell.org/shell
===================================================================
My code (if any) in this post is copyright 2004, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License
- Next message: ynotssor: "Re: [Algorythm] Read-write on a shared file"
- Previous message: xm: "[Algorythm] Read-write on a shared file"
- In reply to: xm: "[Algorythm] Read-write on a shared file"
- Next in thread: xm: "Re: [Algorythm] Read-write on a shared file"
- Reply: xm: "Re: [Algorythm] Read-write on a shared file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
