Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752682AbbFXJzb (ORCPT ); Wed, 24 Jun 2015 05:55:31 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:35544 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752417AbbFXJzX (ORCPT ); Wed, 24 Jun 2015 05:55:23 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 24 Jun 2015 11:55:21 +0200 Message-ID: Subject: Re: kdbus: to merge or not to merge? From: Alexander Larsson To: Andy Lutomirski Cc: Linus Torvalds , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni , Greg KH , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5354 Lines: 97 On Tue, Jun 23, 2015 at 8:06 AM, Andy Lutomirski 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 " 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/