Message-ID: <CALCETrV3OmUD5XrXj_nd4M2ac-ww6sDYScRy4yYbu8xz2zeALg@mail.gmail.com>
Date:	Wed, 24 Jun 2015 07:38:05 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Alexander Larsson <alexander.larsson@...il.com>
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 Wed, Jun 24, 2015 at 2:55 AM, Alexander Larsson
<alexander.larsson@...il.com> 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@...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