Mandatory Access Control was Re: Plans for gnome-vfs replacement

[David Malcolm <dmalcolm redhat com>]

[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]

Hope this helps
Dave

[1] and its autosave files; we patch Fedora so these are inside
~/.evolution rather than ~/ for this reason.