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/

Reply via email to