> -----Original Message----- > From: Patrick Ohly [mailto:[email protected]] > Sent: Tuesday, April 15, 2014 11:56 PM > To: Schaufler, Casey > Cc: José Bollo; Lukasz Wojciechowski; [email protected] > Subject: Re: [Dev] Cynara + DBUS > > On Tue, 2014-04-15 at 18:17 +0000, Schaufler, Casey wrote: > > > -----Original Message----- > > > From: Dev [mailto:[email protected]] On Behalf Of José Bollo > > > Sent: Tuesday, April 15, 2014 9:05 AM > > > To: Lukasz Wojciechowski > > > Cc: [email protected] > > > Subject: Re: [Dev] Cynara + DBUS > > > > > > On lun, 2014-04-14 at 16:07 +0200, Lukasz Wojciechowski wrote: > > > > > > snip > > > > Consider what Rafał Krypa <[email protected]> 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.
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. > > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
