On 11/3/06, toad <toad at amphibian.dyndns.org> wrote: > On Fri, Nov 03, 2006 at 11:02:42AM +1300, Phillip Hutchings wrote: > > 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 > > It's a good idea otherwise. > > I think maybe each client that wants secure access could create an > account. Then it logs in with that account, and the user can decide what > rights to grant it from the web interface?
Sounds good. > > > > > >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. > > I didn't say it protects you against a local root! It also doesn't protect you if you run a malicious client as the same user as a legit one, it's fairly trivial for local app to search a FS for your legit client's store. -- Phillip Hutchings http://www.sitharus.com/
