[Dev] Cynara + DBUS

Patrick Ohly patrick.ohly at intel.com
Wed Apr 16 06:56:12 GMT 2014

On Tue, 2014-04-15 at 18:17 +0000, Schaufler, Casey wrote:
> > -----Original Message-----
> > From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of José Bollo
> > Sent: Tuesday, April 15, 2014 9:05 AM
> > To: Lukasz Wojciechowski
> > Cc: dev at lists.tizen.org
> > Subject: Re: [Dev] Cynara + DBUS
> > 
> > On lun, 2014-04-14 at 16:07 +0200, Lukasz Wojciechowski wrote:
> > 
> > snip
> > > Consider what Rafał Krypa <r.krypa at samsung.com> wrote:
> > >
> > > One assumption for Smack is needed for this model to work: to assign
> > separate Smack labels for the applications. I believe that there is a consensus
> > to go that way.
> > 
> > How will be set the smack policies of DBUS if each application has its Smack
> > Label?
> Good question. Applications will need mutual write access with
> dbus to talk to it. Yes, this introduces additional Smack rules.

So in other words, full access to anything that is on the session D-Bus,
including all other apps. Anything talking on the session D-Bus will
have to be prepared to get potentially malicious messages.

We cannot put unmodified D-Bus services on the session bus, even if they
are only meant to be used by other services or system apps in the "User"
domain. I wonder whether something simpler than patching all these
services can be done. How about this:

      * By default, the D-Bus daemon assumes that a client running in
        the "User" domain was *not* patched to use Cynara.
      * Only processes in the "User" domain are allowed to talk to such
        unpatched D-Bus clients.
      * When delivering messages, the D-Bus daemon itself enforces that
        and  sends back an error reply if the check fails.
      * A client can explicitly tell the D-Bus daemon that it is ready
        to receive messages from all clients, using an extension of one
        of the standard client<->daemon D-Bus APIs (details TBD).

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