[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 08:28:53 GMT 2014


On Wed, 2014-05-14 at 10:33 +0300, Kis, Zoltan wrote:
> On Wed, May 14, 2014 at 9:53 AM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> > 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?
> 
> /usr/bin/dbus-daemon
> 
> >
> > 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
> > installed.
> >
> > Cynara augments static Smack rules with runtime checks in user space.
> > For this to work, each individual D-Bus service has to call Cynara.
> 
> Or, the dbus-daemon (and all other security enforcement points) has to
> run the run-time checks.

Yep, that's my forth option.

I don't know whether that option was considered and discarded for some
reasons. If so, it would be good to hear from those who were in those
discussions.

> Since I am no security expert, all the above is IMHO, needing
> check/confirmation.

Same here. At some point (when Cynara is in Tizen with a usable API
and/or the D-Bus configuration aspect has been clarified) I need to make
use of the available mechanisms to secure the internal D-Bus services in
EDS and the public D-Bus API in SyncEvolution. That's why I am trying to
understand these mechanisms.

-- 
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