I think there are technical problems with this solution. 'client gets some unique identifier'. If some other client takes over the trusted client and reads the password from a config file it could authorize to the node as the trusted client. Unique identification could only be implemented if you use signed classes and certificates that are hardcoded into the node for each client (and per client version). Alot of work and complexity, but true this would be needed to be 100% sure that you can trust a client. But then the issuer of the certificate (some trusted instance) would have to carefully check the source code of the client for malicious code parts before they give the client a certificate... who does and pays this ?
On 11/2/06, Phillip Hutchings <sitharus at sitharus.com> wrote: > On 11/3/06, toad <toad at amphibian.dyndns.org> wrote: > > How about the following?: > > > > 1. Any FCP connection not from localhost is automatically set to > > untrusted mode. > > 2. The user may set a flag indicating that all connections are > > untrusted. > > 3. The user may create one or more username/password pairs for > > authorized access. These are kept in a file readable only by the user > > running the node: > > username:password:keywords > > > > "keywords" contains a list of keywords (config, read-disk, write-disk, > > etc). > > > > I have considered specific limitations on where in the local filesystem > > files can be downloaded to / uploaded from. I'm not convinced that this > > is Freenet's job; if you have untrusted local users (and maybe even if > > you don't), you should run Freenet in a chroot. And if the attacker has > > filesystem access, he can create symlinks etc (which java cannot deal > > with). It is impossible for us to for example fork a subprocess which > > then setuid's to the user in question. So I say we shouldn't get into > > that, since we can't do it well. > > I was thinking something like this: > - When an FCP client connects it gets a unique identifier of some sort > - By default FCP clients have no rights for 'dangerous' operations, > except fproxy. The node could generate a key for fproxy and store it > somewhere with no world/group permissions > - If you want to upgrade an app to have those permissions you have to > go to fproxy (or another authorised app) and add the permissions, > kinda like how flickr does it > > Downsides: > - All clients need to be aware of it, FCP will have to change > - Still doesn't protect against local attacks, but will protect from > forwarding attacks > - Harder to implement > > Upsides: > - Users don't need to worry about passwords... > > -- > Phillip Hutchings > http://www.sitharus.com/ > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech >