On Wed, Nov 01, 2006 at 10:41:59PM +0100, bbackde at googlemail.com wrote: > This sounds as if you are not willing to implement easy to use and > easy to understand stuff into the node. > You say that the client must handle it, you do not want to do anything for > it. > What about clients that just do not provide a password prompt? What to > do for the paranoid people? Nothing?
An arbitrary, total ban on dangerous operations across all FCP clients seems a rather blunt instrument to me. There must be a better way. > > Please, implement some of this things into the node rather than to > shift all the work to the clients. They could fail, and this would > compromise the anonymity of the (unsuspecting) user. If the node > implements it there much lesser ways for the user to fail. Implement what exactly? That's the problem. > > And regarding dda: if the user tells the node to not to use dda then > the node should do it. Even if you say it saves so much disk space. If > the user is aware of this disable it. Well of course. But I do think that clients should support direct disk access, because it really does save a significant amount of disk space. > > On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > >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 > >> > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.5 (GNU/Linux) > > > >iD8DBQFFSQsPA9rUluQ9pFARAp8yAJ43NIBj6VTS/q3GjPZcNMGAVJpERwCfdbSR > >98BkPd1ubdg9xH56d1BhD10= > >=Q46z > >-----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/20061102/868c56f8/attachment.pgp>
