[Dev] enforcing priviliges of web apps (was: Re: New Tizen Bluetooth Framwork (NTB) wiki page)

Patrick Ohly patrick.ohly at intel.com
Wed May 14 06:53:41 GMT 2014

On Wed, 2014-05-14 at 00:51 +0300, Kis, Zoltan wrote:
> In this model, native apps could also access the platform DBUS
> interfaces, and security needs to be enforced e.g. in the DBUS daemon
> (by assumed Cynara extensions to the dbus daemon).

When you say "the dbus daemon", do you mean the /usr/bin/dbus-daemon or
the D-Bus service providing a certain interface?

In the current Cynara model, the dbus-daemon was meant to be unchanged,
ie. would not call Cynara. There are the Smack-aware access controls,
but as far as I understand those controls, they are too static and/or
hard to manage once apps with different Smack rules and manifests get

Cynara augments static Smack rules with runtime checks in user space.
For this to work, each individual D-Bus service has to call Cynara.

We cannot count on all D-Bus services doing this properly, so the system
default for unmodified upstream D-Bus services has to be "User resp.
System domain can access them, apps can't". But even in such a system,
the session D-Bus must be accessible by all apps, because the
Cynara-aware services there will have to be accessible to apps.

> The main drawback here is the need to map every single platform
> functionality to a new API, and then which API? The C API? OSP/C++?
> ASD IDL->C++? An intermediate 'mother of all' API to which all
> previous are mapped? Looks very idealistic/irrealistic to me, given
> the limited time and resources we have. Also, the optimal process
> model of the service proxy is not clear.

I share these concerns.

The way I see it, we need three options and the ability to choose on a
case-by-case basis:
     1. Proxy daemon where the API is clear.
     2. D-Bus rule-based filtering (with the current Smack support).
     3. Cynara called by D-Bus services.

Perhaps there's a forth option:

 4. Cynara called by dbus-daemon, based on service configuration.

The advantage of option 4 over 3 is that we don't need to touch the many
entry points into upstream services. However, it depends on Cynara
behaving well inside the dbus-daemon event loop - blocking synchronous
calls definitely will be a showstopper there. It also won't work well
with kdbus.

Also note that we need 2 for 3 to be secure. Apps must be able to send
method call messages and receive their replies and signals, but they
must not be allowed to see anything going via the bus which they don't
have access to. This needs to be controlled by dbus-daemon; it's outside
of the control of Cynara-aware services.

Can some security expert please take the AR to investigate how option 2
with a secure default (apps cannot talk to services and will not receive
any signals) and exceptions (for Cynara-aware services) can be

If this is not possible, then the only remaining alternative is to
prevent apps from accessing any D-Bus session (user or system) and
implement the proxy approach for certain APIs. This is probably not good
enough for IVI.

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

More information about the Dev mailing list