On Thu, Nov 02, 2006 at 10:26:38PM +0100, bbackde at googlemail.com wrote: > 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 ?
Not possible; requires TPM. What you could do is have the client generate a certificate on first use. > > 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 > > > _______________________________________________ > 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/a279386e/attachment.pgp>
