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

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]