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>

Reply via email to