On Fri, Nov 03, 2006 at 09:36:49AM +1300, Phillip Hutchings 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
Implies strong authentication, to prevent a client from just logging in and pretending to be another client. Which would have to be optional, to avoid complicating matters for clients that don't need it. > - 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 Why doesn't it protect against local attacks? > - Harder to implement > > Upsides: > - Users don't need to worry about passwords... -------------- 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/d353966a/attachment.pgp>