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.
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.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
