David Malcolm wrote: > [adding sgrubb, dwalsh and walters to CC] > > On Mon, 2006-09-18 at 18:12 +0200, Alexander Larsson wrote: > > [snip intro paragraph] > > >> So, I think the time has come for a serious look at what gnome-vfs >> could be. I've spent much time last week thinking about the weaknesses >> and problems of the current gnome-vfs and possibilities inherent in a >> redesign, both having learnt from 7 years of gnome-vfs existance and >> the improvements in the platform (both Gnome and surrounding >> technologies) since 1999 when it was designed. >> > > [snip list of problems with existing approach] > > >> Having a global stateful model means all non-local vfs accesses go >> through the vfs daemon. This works pretty well with the smb backend in >> the current gnome-vfs, and smb is the backend most likely to have high >> bandwidth traffic, so this doesn't seem to be a large performance >> problem. Although we do have to take the performance aspect into >> consideration when designing the daemon. >> >> In order to avoid all the problems with threading described above the >> vfs daemon will not use threads. In fact, I think the best approach is >> to let each active mountpoint be its own process. That way we get >> robustness (one mount can't crash the others) and simplify the backend >> creation greatly (each backend fully controls its context). It also >> will let us do concurrent access to e.g. two smb shares (like a copy >> from one to the other). We can't really do this atm since the thread >> lock in the smb backend serializes such access. But with two smb >> processes this is not a problem. >> > > Thinking aloud here: I wonder if people using Mandatory Access Control > (SELinux, AppArmor, Trusted Solaris) might want to have an option to > have all file access go through a backend - even local file access. > > I've long wanted to lock down Evolution so that it doesn't have access > rights to local files, so that if someone constructs a 0-day email > exploit that owns your evolution process, the resulting mess (running as > you) isn't allowed access to arbitrary files owned by you. > > If all local file access under direct user control (browsing, opening > and saving "documents") is performed by a dedicated process running as > the user within his/her session, that process can be given broad access > rights to the user's files. > > If this is available we can lock down GNOME apps so they only have the > rights they need. That way, for instance, evolution can be locked down > so that it can only read ~/.evolution and below [1]; adding an > attachment to an email would require the evolution process to ask the > VFS backend process for the content of the file, rather than loading it > directly. > > This doesn't fully close the hole, since the owned app still has the > right to make vfs API calls as before and a hostile payload could work > that way - but it may make some exploits harder. (Maybe there's a way > to implement a trusted filechooser and only allow the app access to > files which the user has selected in the GUI? can this be done without > having the filechooser out-of-process from the main app?) > > [snip discussion of URLs and statefulness] > > A lot of what you want can be done with SELinux, now but controlling what the user can get is the difficult part. A while back we brainstormed on somehow making the chooser a different application and allowing it to hand the file to the calling app. One possibility for SELinux would be to create a copy of the file and label it such that evolution could read the copy, and then send it.
Adding the SELinux Internal list for comment. > Hope this helps > Dave > > [1] and its autosave files; we patch Fedora so these are inside > ~/.evolution rather than ~/ for this reason. > > _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
