Re: SELinux directory polyinstantiation and gvfs

[David Zeuthen <david fubar dk>]

On Wed, 2009-09-16 at 09:00 -0500, Xavier Toth wrote:
> On Wed, Sep 16, 2009 at 8:43 AM, David Zeuthen <david fubar dk> wrote:
> > On Wed, 2009-09-16 at 08:25 -0500, Xavier Toth wrote:
> >> We develop a system using SELinux MLS policy and are polyinstantiating
> >> a number of directories based on context and level (man pam_namespace
> >> and namespace.conf). For example we polyinstantiate /tmp. In our
> >> configuration pam_namespace mounts /tmp on another directory
> >> /tmp.inst/<hash representing the context and level>. Now let's say a
> >> user saves a page in firefox to /tmp and then brings up nautilus and
> >> tries to find the saved page. Well they won't find the saved page in
> >> /tmp but rather in a subdirectory of /tmp.inst which will be
> >> confusing. So our question is can gvfs be used in some way to alter
> >> the representation of the file system to hide the complexity of
> >> polyinstantiation?
> >
> > I don't think GIO/GVfs can be of much help here.
> >
> > I'm curious why you'd want firefox and nautilus instances in the _same_
> > session to see different /tmp directories - seems like a lot of things
> > would break this way. Why?
> 
> Indeed this is the point I want everyone to see /tmp and not have to
> know about /tmp.inst the ugliness of polyinstantiation.

By everyone, do you you mean "all apps in the same session" or "all apps
owned by the same user"? I presume it's the former.

Have you looked at the xguest work by Dan Walsh? I think these scripts
sets up a per-session /tmp (and also $HOME and other things since xguest
is for transient guest accounts) on a tmpfs that is cleared when the
session terminates. For example, see

  http://danwalsh.livejournal.com/13936.html

I'm also not sure exactly how a per-session /tmp is related to
multi-level security as your initial mail indicated. But I'll share some
thoughts on multi-level security and the desktop anyway. I'm not sure
it's useful information (mostly because I don't know exactly what you
want to achieve) so take it or leave it as is.

The way GNOME, KDE and many other desktop environments work is that we
have a ton of IPC between apps in the same session. This includes both
X11 (cut and paste, screenshots), CORBA (accessibility; both input and
output; control of other apps, e.g. magnifier and on-screen-keyboards)
and D-Bus (for various services, e.g. IO, keyring services and so on).
So attempting to treat each app as a separate security domain is not
really going to work unless you heavily modify the app.

I mean, if you start locking down things on the protocol levels (in the
same way you confine user-space processes with SELinux - e.g. deny
system calls) things will start to fall apart. For example, if you
confine the firefox process so it can't speak to the GVfs daemon (via
D-Bus), then suddenly the file chooser in Firefox will stop working
because the firefox process can't speak to, say, the gvfsd-sftp process.
Firefox itself of course don't know anything about this - it just
happens to use the GTK+ file chooser which uses GIO which uses GVfs
which uses D-Bus. Similarly, if you confine firefox from using CORBA,
suddenly accessibility stops working and people with disabilities can't
use the onscreen keyboard or braille readers (and section 508 is not
optional).

So I'm pretty sure that the only realistic way to do multi-level
security on the desktop is by modifying the apps you care about.
Typically by having the chrome and the content renderer processes
separate. Much like Google Chrome is doing where the chrome is trusted
and the content-renderer is untrusted. And you can do it the other way
around too. For viewing top-secret information, maybe your
content-renderer is trusted (since it can read the top-secret document)
but it may treat the chrome (that actually displays the pixmap rendered
by the content renderer) as untrusted and refuse to provide the rendered
document to the chrome (for example, it may refuse to do this unless the
user is in a secure location (whatever that may mean)).

The bottom line here is that we treat the whole desktop login session as
a single security context and if you start changing that, lots of things
will just stop working.

Anyway, just some thoughts.

    David