[Dev] Cynara + DBUS
casey.schaufler at intel.com
Wed Apr 16 15:30:47 GMT 2014
> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Tuesday, April 15, 2014 11:56 PM
> To: Schaufler, Casey
> Cc: José Bollo; Lukasz Wojciechowski; dev at lists.tizen.org
> Subject: Re: [Dev] Cynara + DBUS
> 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
> > > to go that way.
> > >
> > > How will be set the smack policies of DBUS if each application has its
> > > 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.
No, that's not what I said, I don't think. It's one thing to talk to
dbus, it's another to talk to services using dbus.
> 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:
This is true if the service provides and "privileged" services.
This is true if they use dbus or UDS.
> * By default, the D-Bus daemon assumes that a client running in
> the "User" domain was *not* patched to use Cynara.
dbus shouldn't care. It looks at the dbus Smack configuration.
> * Only processes in the "User" domain are allowed to talk to such
> unpatched D-Bus clients.
We could put this into the dbus configuration, but again, any process
providing "privileged" services has to enforce the policy.
> * When delivering messages, the D-Bus daemon itself enforces that
> and sends back an error reply if the check fails.
More of the same, I think.
> * 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).
That's dbus configuration, but we're back to the fact that providing
"privileged" services requires that you check your caller.
> 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