Starting the kdbus discussions

John Johansen john.johansen at canonical.com
Fri Jan 3 18:06:02 PST 2014


On 01/03/2014 03:31 PM, Lennart Poettering wrote:
> On Fri, 03.01.14 14:12, John Johansen (john.johansen at canonical.com) wrote:
> 
>>>> I'm not sure I understand the suggestion to use Policykit. When confining an
>>>> application, you want to block all access to the objects available on the
>>>> session bus, and, depending on the rights you want to grant to the specific
>>>> application, selectively allow certain paths, interfaces, method names. Using
>>>> Policykit for this would mean every single application that offered methods on
>>>> the session bus would need to integrate with policykit and perform its own
>>>> access control. I'm not even sure how you would do that if you have multiple
>>>> untrusted applications running.
>>>
>>> Well, it's generally not applications talking to other
>>> applications. It's mostly applications talking to desktop services. And
>> Except when you start allowing application to advertise or replace services,
>> this is done all the time in android.
> 
> Ahm, no. In Android this is done via "intents". apps never talk directly
> to each others on android, they can just register handlers for intents
> and some system component then arbitrates between them, without them

yes I simplified the effect is like they are talking to each other and going
through intents is one way to achieve this

> knowing much about each other. The intents stuff is an interactive way
> to transition between two security domains. It's a great idea actually.
> 
yes. Quite similar to uhm offering a service at a well known address without
the application knowning/caring who its talking to and letting the system
arbitrate between them

> This is what we are trying to make work for the general Linux landscape
> under the "Portals" name, as discussed at last GUADEC.
> 
sure, though its a shame that that discussion happenend at GUADEC instead
of say LSS

> (Instead of doing your own proprietary Canonical thing regarding
hrmmm there is nothing proprietary that I am aware of. There have been
open discussions and documentation about what is being done. None of it
has to be Canonical specific, and much of it isn't even apparmor specific.

> sandboxing it might actually be worth talking to people in the Linux
> world about these things, then you'd know things like this).
> 
err thats quite the assumption, we have talked to people and do know
about them.

The fact is much of the work has moved in parallel to other work in the
community. There are competing desktops, init daemons, sandbox designs
and LSMs.




More information about the dbus mailing list