On Wed, Nov 01, 2006 at 09:26:03PM +0100, bbackde at googlemail.com wrote: > 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. > Untrusted clients wouldn't be given the password. What's the problem?
> 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 What if you are e.g. running Fproxy over FCP? It seems to me that it would be useful to be able to have some clients trusted and others not. And I don't want yet another reason not to use direct disk access; direct disk access saves _a lot_ of disk space. One interesting possibility would be to disallow dangerous operations on non-localhost connections, but even then you have to worry about ssh forwarding. > > 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 > > > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20061101/8b18b7ca/attachment.pgp>
