On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > On Wed, Nov 01, 2006 at 09:04:43PM +0100, bbackde at googlemail.com wrote: > > A user can run clients in a VM or on another box for exactly this > > reason (some users do this right now). This way bad clients cannot > > read more files than their own, and they cannot read node config > > files. The only way to do bad things is the FCP2 interface. And their > > must be a way to prevent those kind of dangerous kind of access, at > > least via an option in the node (the most easy way to do it. Only > > requires to ensure an unfaked node). > > > > true? > > Maybe. What would you suggest? The easiest thing is a simple password > necessary for dangerous operations. But then, what operations are > dangerous? Some more than others! Is running unknown clients in a VM > common?
Passwords are useless if a client is corrupted. If a client stores the password the corrupted client can use it. If a client asks for permission it would be ok, but annoys the user. I would suggest to add a node parameter "paranoiaMode=true" that disables: - direct disk access (only socket connections allowed) - the send of any worthful NodeInfo stuff like keys - and probably more Disallow anything that could access the box where the node runs. Only pure FCP2 is allowed. > > > > On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > >Bad clients can read (and write!) all your files anyway. Secure plugins > > >have been proposed but will be significant work. > > > > > >On Wed, Nov 01, 2006 at 08:32:36PM +0100, bbackde at googlemail.com wrote: > > >> Ok I understand. But its not easy for users to separate good from > > >> faked freenet clients. > > >> > > >> Maybe all clients should sign their binary code in the jar file to > > >> enure its unchanged. And maybe there is some way to provide a > > >> certificate to the node. Then the freenetproject people could check > > >> the code of clients apps and give them a certificate that is hardcoded > > >> in the freenet node. Only apps that have this certificate are allowed > > >> to connect to the node if the user configured the "high security > > >> mode". > > >> Updating the node together with new clients is not too much work and > > >> is acceptable for users. > > >> > > >> I don't know about the details of signed java code,... > > >> > > >> Maybe this would be a good item for the todo list (on > > >> bugs.freenetproject.org)? > > >> > > >> On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > >> >You are wrong. Anyone with access to FCP can already: > > >> >- Upload arbitrary files which the node can access. > > >> >- Read your node reference, your peers and your config > > >> >- Add or remove peers > > >> >- Change config options > > >> >- Write to arbitrary non-existent files which the node can access > > >> > > > >> >It has been suggested that a simple password or a full > > >> >username/password login might be useful. Nothing was ever really agreed > > >> >or implemented. > > >> > > > >> >So be careful who you let have FCP access! > > >> > > > >> >On Wed, Nov 01, 2006 at 07:36:48PM +0100, bbackde at googlemail.com > > >> >wrote: > > >> >> Is it true what I see, is each FCP2 client now able to retrieve the > > >> >> private DSA key from the node, the key that uniquely identifies your > > >> >> node??? > > >> >> > > >> >> Do you think this is a nice feature? Someone could hack some existing > > >> >> open source application, provide them to some incautious users and > > >> >> send their private DSA key to some big brother for analysis??? > > >> >> > > >> >> I don't want to accept this without an important reason. I have no > > >> >> idea what a client could do with this private key, except to send it > > >> >> to some big brother. > > >> >> > > >> >> Or am I wrong? > > >> > > > >> > > > >> >-----BEGIN PGP SIGNATURE----- > > >> >Version: GnuPG v1.4.5 (GNU/Linux) > > >> > > > >> >iD8DBQFFSPACA9rUluQ9pFARAn/OAJ4uWpvQzVJ+AZY3dIANIkcAeHRsCgCfUiEP > > >> >TiZxr4+gbS4u+0iU7tM6JdM= > > >> >=ao4L > > >> >-----END PGP SIGNATURE----- > > >> > > > >> > > > >> >_______________________________________________ > > >> >Tech mailing list > > >> >Tech at freenetproject.org > > >> >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> > > > >> > > > >> _______________________________________________ > > >> Tech mailing list > > >> Tech at freenetproject.org > > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> > > > > > > > > >-----BEGIN PGP SIGNATURE----- > > >Version: GnuPG v1.4.5 (GNU/Linux) > > > > > >iD8DBQFFSPpMA9rUluQ9pFARAttWAJ96NdhGKQgkMuZRcMsLU26W3vuaMwCfcjvT > > >vBdp6Ce0esREBFPdt5kKAWo= > > >=gIIZ > > >-----END PGP SIGNATURE----- > > > > > > > > >_______________________________________________ > > >Tech mailing list > > >Tech at freenetproject.org > > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > > > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFFSP6EA9rUluQ9pFARAuKtAKCPUt/lvoXA5y/SSfWk3lJLYsA49QCdG7yK > yz+w9o6BOLfn/Em57p82VBc= > =MmKB > -----END PGP SIGNATURE----- > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >
