Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753287AbbFXOie (ORCPT ); Wed, 24 Jun 2015 10:38:34 -0400 Received: from mail-lb0-f179.google.com ([209.85.217.179]:35822 "EHLO mail-lb0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752970AbbFXOi1 (ORCPT ); Wed, 24 Jun 2015 10:38:27 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Wed, 24 Jun 2015 07:38:05 -0700 Message-ID: Subject: Re: kdbus: to merge or not to merge? To: Alexander Larsson 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: 5930 Lines: 123 On Wed, Jun 24, 2015 at 2:55 AM, Alexander Larsson wrote: > > 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 find myself wondering whether the change I complain about will be a problem down the road. It's certainly an information leak of some sort. Whether the information that it leaks is valuable to anyone is an interesting question. > > 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.* Aha! You're not doing what I assumed you were doing at all. > > 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. Do I understand correctly that you're committing to an iOS-like model in which activations go to a particular named app as opposed to a more Android-like model in which multiple providers can offer the same service? > > 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. [snip description of what the portal does] This seems generally sensible. Here are my concerns. Feel free to tell me I'm nuts or ask me more. 1. Other than allowing non-sandboxed code to contact sandboxed apps directly (as opposed to via the portal), I still don't see how this is better than having a completely separate kdbusfs instance (or userspace socket or whatever) per app. The only things on the outside the app talks to are org.freedesktop.portal.*, and whatever service provides them could be taught to provide them to more than one running sandboxed app. By doing it with a policy rule like this, you're at risk of random non-sandboxed programs having a bright idea to offer some completely insecure service with a name like "org.freedesktop.portal.badidea" that destroys security. See, for example, the tons of reports of exploitable Android system services that shouldn't have been there in the first place. By using this type of policy rule, you're also preventing meaningful use of two different portal implementations -- their names will collide. That's fine when there's exactly one implementation that you're developing, but it might be nice to be able to run some apps under a super-locked-down portal, some under a standard portal, and some under some other fork of the portal, all at once. 2. Without seeing more details, I don't see how you will defend against name collisions. By allowing a sandboxed application to claim a well-known name with global significance (e.g. org.freedesktop.gedit), you're vulnerable to apps that maliciously claim some other app's name (e.g. by sticking it in their manifest or whatever). Search for the iOS "XARA" attacks, which mostly work like this and almost completely break iOS security (currently unfixed AFAIK). 3. Due to the IMO absurd way that kdbus policy works, you think you're limiting sandboxed apps to talking to names that match entries in your policy table. Instead, you're limiting sandboxed apps to talking to peer ids that advertise names that match entries in your policy table. As I understand it, you are completely and utterly hosed if your portal implements org.freedesktop.portal.secure_printing and org.freedesktop.admin.something_else. This issue is a large part of the reason that I consider kdbus' policy framework to be an unacceptable design. > 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. I don't think you should make up policy dynamically. I thought you were and I was confused. If you use per-sandbox busses or sockets, you completely avoid needing to muck with cgroups names. You know a priori which request comes from which sandboxed app because it could only have come from one place. --Andy -- 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/