[Dev] enforcing priviliges of web apps

Schaufler, Casey casey.schaufler at intel.com
Thu May 15 17:02:14 GMT 2014


> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Thursday, May 15, 2014 8:12 AM
> To: Schaufler, Casey
> Cc: Kis, Zoltan; Rafał Krypa; dev at lists.tizen.org
> Subject: Re: [Dev] enforcing priviliges of web apps
> 
> On Thu, 2014-05-15 at 14:38 +0000, Schaufler, Casey wrote:
> > > -----Original Message-----
> > > From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Kis,
> > > Zoltan
> > > Sent: Thursday, May 15, 2014 3:45 AM
> > > To: Rafał Krypa
> > > Cc: dev at lists.tizen.org
> > > Subject: Re: [Dev] enforcing priviliges of web apps
> > >
> > > On Thu, May 15, 2014 at 1:27 PM, Rafał Krypa <r.krypa at samsung.com>
> > > wrote:
> 
> > > Very nice, thanks! That leaves either A, B1(a), or B2 as options,
> > > the main issue being to patch dbus-daemon for supporting Cynara and
> > > hence allowing direct access from native apps and crosswalk
> > > extensions. What is your take on this?
> >
> > It is already possible to configure dbus to control access based on
> > Smack labels. There should be no need to change dbus. There will need
> > to be dbus configuration written for those services.
> 
> Such a configuration is static: access is either allowed or denied.
> 
> With Cynara, one could (at least in theory) grant access temporarily and/or
> after asking the user.

Point.

> The problem for a hypothetical, patched dbus-daemon calling Cynara will be
> to identify the session. Probably it will not have enough understanding of the
> D-Bus interfaces that it is asked to protect to provide a meaningful identifier.

I don't know what you mean by "identify" the session, but expect that
it would be a matter of configuration. Not necessarily simple configuration,
mind you.

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