Re: [Algorythm] Read-write on a shared file
From: xm (xm_at_ca.inter.net)
Date: 08/01/04
- Next message: Sam: "Re: Spammers Want You To Believe That (Challenges from challenge-response systems qualify as unsolicited bulk mail) [was: the part in parentheses]"
- Previous message: Moe Trin: "Re: pppd/chat dialup"
- In reply to: Chris F.A. Johnson: "Re: [Algorythm] Read-write on a shared file"
- Next in thread: ynotssor: "Re: [Algorythm] Read-write on a shared file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 1 Aug 2004 14:02:20 -0700
You had quite a few questions here, I guess it's my fault being
unclear... I'll try to clarify things as mush as possible.
> 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.
Exact. At the start, one computer has the file, then it is propagated
and after a while, after a few modifications, it becomes clear that
the file may be different on some computers (in need of update on that
file).
> > 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?
Peer-to-peer? It is not a stable solution, but that is irrelevant in
this discussion.
> If one cannot write to it, one cannot change it.
Anybody can change anything, but they must not be allowed to or if
they succeed the changes must not give them more power or change the
file on the network.
> > Moreover, let say part of that file must be unreadable or encrypted
> > to specific individuals.
>
> An entirely different issue.
Right, let's forget about this.
> > 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?
The program has read/write access to the file created under a user's
directory for example. Within the program, it will deny you the
access to the file and if you modify it externally, it will overwrite
with the real file on the network.
So there will be an exchange protocol, to ask the network to 'commit'
changes to the file or to 'get' the file in question.
> > 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?
The program dealing with this special shared file, it's still just
theory, but I'm trying to understand how it is possible to strenghten
this very insecure file.
> > 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?
As I said earlier (as also said to forget about it) some portions of
the file will be encrypted, so overwritting them will destroy the
information. But some other parts will not be encrypted, those may be
changed locally, but still it should not give the user more power over
the other files (other shared files, same way as this one).
> If the file should not have read and permissions write for all
> users, fix the program that's writing it.
No, the program will be used by users, they will install it and run it
for themselves, they will have write access on all those installed
files.
The program should check for modifications though, either by verifying
some checksum previously taken or by verifying some checksum from the
network.
> > 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?
Ok, that's the other question we can forget...
> > 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.
Read/write permissions from the system must be different that the rw
permissions from the program. The program should crash hard if you
modify its files, for example.
> > 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?
Everything's fine here...
> > 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.
If the machine is compromised there is nothing that can be done,
except, if there are clues the computer has been compromised that it
could be flaged as being suspicious.
> > 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.
Well, we would need a mechanism to find if a computer has been
compromised in the first place.
In my sense, when a host is compromised, I've learned to think of the
host as being in Total control of the hacker, therefore, it is
impossible to know if a host is compromised, it only is possible at
the time where the hacker forces his way in. So my point would be,
even if the host is compromised, there would still be some security
check that he would have to go through to make the modification.
If a single authentification/handshake can solve this problem then
I'll be glad, but I feel there is more to it.
Thanks,
xm
- Next message: Sam: "Re: Spammers Want You To Believe That (Challenges from challenge-response systems qualify as unsolicited bulk mail) [was: the part in parentheses]"
- Previous message: Moe Trin: "Re: pppd/chat dialup"
- In reply to: Chris F.A. Johnson: "Re: [Algorythm] Read-write on a shared file"
- Next in thread: ynotssor: "Re: [Algorythm] Read-write on a shared file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
