On 11/3/06, toad <toad at amphibian.dyndns.org> wrote: > 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.
Yeah, I think that sounds the end of this idea > > - 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? You could copy another client's token if you have local FS access and people aren't careful. > > - Harder to implement > > > > Upsides: > > - Users don't need to worry about passwords... -- Phillip Hutchings http://www.sitharus.com/
