Message-ID: <CAHr-LrZEYAGE9xZZ7eyTUa-tThWNwN5_R0dMAg6wzjxK9i63AQ@mail.gmail.com>
Date:	Wed, 24 Jun 2015 11:55:21 +0200
From:	Alexander Larsson <alexander.larsson@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Havoc Pennington <havoc.pennington@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>
Subject: Re: kdbus: to merge or not to merge?

On Tue, Jun 23, 2015 at 8:06 AM, Andy Lutomirski <luto@...capital.net> wrote:

> 3. The sandbox model is, in my opinion, an experiment that isn't going
> to succeed.  It's a poor model: a "restricted endpoint" (i.e. a
> sandboxed kdbus client) sees a view of the world defined by a limited
> policy language implemented by the kernel.  This completely fails to
> express what I think should be common use cases.  If a sandboxed app
> is given permission to access, say,
> /org/gnome/evolution/dataserver/CalendarView/3125/12, then it knows
> that it's looking at CalendarView/3125/12 (whatever that means) and
> there's no way to hide the name.  If someone subsequently deletes that
> CalendarView and creates a new one with that name, racelessly blocking
> access to the new one for the app may be complicated.  If a sandbox
> wants to prompt the user before allowing access to some resource, it
> has a problem: the policy language doesn't seem to be able to express
> request interception.
>
> The sandbox model is also already starting to accumulate kludges.
> Apparently it was recently discovered that the kdbus connection
> lifetime model was incompatible with sandbox policy, so as of a recent
> change [2] connection lifetime messages completely bypass sandbox
> policy.  Maybe this isn't obviously insecure, but it seems like a bad
> sign that "it's probably okay to poke this hole" is already happening
> before the thing is even merged.
>
> I'll point out that a pure userspace implementation of sandboxed dbus
> connections would be straightforward to implement today, would have
> none of these problems, and would allow arbitrarily complex policy and
> the flexibility to redesign it in the future if the initial design
> turned out to be inappropriate for the sandbox being written.  (You
> could even have two different implementations to go with two different
> sandboxes.  Let a thousand sandboxes bloom, which is easy in userspace
> but not so great in the kernel.)

I don't really understand this objection. I'm working on an
application sandboxing model for desktop applications (xdg-app), and
the kdbus model matches my needs well. In fact, I'm currently using a
userspace filtering proxy that implements exactly the kdbus policy
model. Of course, this adds *yet* another context switch per message.
The only problem I found is that kdbus filtering broke the ability to
track the lifetime of clients[1]. However, this has now been fixed
with exactly the change you complain about above.

I definitely don't want to do low level request interception with UI.
We learned long ago that it is a very poor fit for desktop use. At the
interception point you have no context at all about the larger scope,
such as what window caused the operation and how you would make it
modal or even just get the window parenting right. Also, if you do
this you will keep popping up windows all the time as apps do calls in
the background to be able to e.g. gray out unavailable menu items,
update folder counts, etc. Any operation that may cause user
interaction must be carefully designed to handle this.

The way I expect to use kdbus policy, for an app called say
"org.gnome.gedit" is to have the following policy:
TALK org.freedesktop.DBus
OWN org.gnome.gedit
OWN org.gnome.gedit.*
TALK org.freedesktop.portal.*

This allows the app to conntect to and talk to the bus, own its own
name and broadcast signals. It also lets anyone else (that are not
sandboxed) talk to the app and it will be able to reply. This is
enough to have regular dbus activation of  desktop files[2], as well
as allowing app-related custom services.

It also allows the app to talk to a set of "portals" which are
sandbox-specific APIs that supply the necessary services for sandboxed
apps to interact with each other and the host. For instance, it would
have APIs for file choosing, where all user interaction will happen on
the host side and the app just gets back the file data. Another
example is sharing with intents-like semantics, where you'd say "I
want to share text <foo>" and we open a dialog on the host side
allowing you to chose how to share the text (tweet it, open in other
app, etc) without the app knowing anything about it other than
supplying the data.

Operations like these are safe because they are interactive. An app
can't use them to silently read the users files, and the user can
always interactively abort the operation if it was unexpected.

Now, there will likely be a few cases where we need a more
fine-grained access limit. For instance you may have a service that
dynamically grants access to particular objects in a portal service to
an app. These things can be implemented fine in userspace in the
actual service itself. The way I do that currently is by looking at
the peer cgroup name, which encodes the xdg-app id. I don't see how
making up policy dynamically and uploading it to the bus is better
than just doing the filtering in the portal.

[1] http://lists.freedesktop.org/archives/dbus/2015-May/016670.html
[2] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists