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

[Daniel J Walsh <dwalsh redhat com>]

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.
>
>