Re: Sandboxed Gnome apps

[Alexander Larsson <alexl redhat com>]

On fre, 2014-09-05 at 13:20 -0500, Federico Mena Quintero wrote:
> On Thu, 2014-09-04 at 19:05 +0200, Alexander Larsson wrote:
>
> > 4. IPC stability guarantees
>
> During GUADEC, Dodji Seketeli told me about a tool he's working on to
> determine whether a C/C++ API/ABI has changed.  This is not IPC
> stability, of course, but it may definitely come in handy to ensure the
> general sanity of the ABI.
>
> http://gcc.gnu.org/wiki/ABIInstrumentation

Yeah, this could be used to inspect ABI compat over time for the same
runtime (i.e. minor releases). It is also interesting wrt builds of the
runtime from different sources (say a distro rebuild of the gnome-os
runtime).

> It should be easy to do a comparison of DBus interfaces, right?  I guess
> you could introspect them, serialize the results, and compare them.  I
> don't know how this would work without having to introspect both pieces
> of code you are testing.

Well, once you have the serialized results it should be possible to at
least assure some level of compat (i.e. no methods removed or changed),
although details wrt implementations would be harder to catch. However,
it is not so easy to do the introspection, as that requires the app to
be running and the list of object names, paths, and exposed interfaces
must be known a priori. If we had a list of all the exposed things and
they were all activatable then it would be easy to at least introspect
the toplevel interfaces (i.e. the ones global to an app, but not
necesarrily ones on objects that you have to call into the API to create
first.)
  
> > 5. Sandboxing APIs
> >
> >    In a sandboxed environment app code doesn't have access to most of
> >    the host system. However, apps still need some ways to securely
> >    access various services (like users files, hw, host services, etc).
> >    We need to define these APIs, and whatever security layer protects
> >    against their misuse.
>
> Does anyone have ideas for how to sandbox a traditional app so as to
> restrict its access to files, DBus onto other processes, etc. - even if
> the app doesn't work at first?  I'd like to see where things start
> failing and then seeing how to open up those bits via DBus interfaces,
> rather than taking an everything-open application and closing it down.

I sympathize with this wish. Its much better to start from a completely
locked down environment and then open up only what is required, as this
is much more secure than going from open to closed by slowly removing
things. Its so easy to forget something.

I've hacked up some simple tool to let me run something with a /usr from
a runtime. It would be simple to modify it so that it sees nothing of
the host (be it filesystem or dbus daemon). However, for it to work at
all it needs an X connection (which is inherently unsafe) and to slowly
start adding dbus interfaces we need to expose it to the bus, and once
it is there its not atm easy to do dbus limits on a more fine grained
level. Maybe we could use the uid or selinux dbus limits to play with
this?