[Dev] Some Tizen Platform Security Confusion
casey.schaufler at intel.com
Wed Aug 6 17:38:33 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Dominig ar Foll
> (Intel OTC)
> Sent: Wednesday, August 06, 2014 1:19 AM
> To: dev at lists.tizen.org
> Subject: Re: [Dev] Some Tizen Platform Security Confusion
> it must also be noticed that services which need to protect conflict to
> resources access induced by multi user and were expecting to get that
> protection (not directly related to security) handle at the SAPI demon
> need now to provide that protection by themselves and that will not be
> possible to add in the dbus server.
> In that case the conflict protection will have to be included in a
> dedicated daemon.
Of course. Services that don't differentiate by user
usually can't be made to do so by dbus configuration.
Our Comms framework has many favorable aspects,
but its lack of user awareness isn't one of them.
> Example would for example to restrict pairing of a phone to the user who
> did it but accept to share the pairing of a remote control.
> Dominig ar Foll
> Senior Software Architect
> Open Source Technology Centre
> Intel SSG
> Le 06/08/2014 02:25, Schaufler, Casey a écrit :
> > There appears to be some confusion about the current plan
> > for enforcing application level privilege in Tizen 3. After investing
> > serious consideration in the Service API (SAPI) scheme it became
> > clear that instead of reducing effort, cost and risk there was a
> > real possibility that it would do just the opposite. The services that
> > could use the mechanism were proving more complex, and there
> > proved to be fewer of them than originally anticipated. SAPI
> > eligible services seem to be the exception rather than the rule.
> > One of the most important observations from the effort is
> > that dbus is very heavily used by the Tizen system services.
> > We are taking advantage of this dependence on dbus by
> > integrating Tizen application privilege processing in dbus.
> > In most cases services that already use dbus will be able to
> > support the Tizen application privilege model using proper
> > dbus configuration. The Cynara team is working closely with
> > the dbus maintainers.
> > The service applications that provide protected application
> > resources that do not use dbus may seem to have a tougher
> > row to hoe without SAPI, but that is actually not the case. The
> > access checks that are the responsibility of the service would
> > have had to have gone into the service daemon and the protocols
> > emulated.
> > The current plan is to use dbus configuration where convenient
> > and add access checks (Cynara) to services that do not use dbus.
> > There may be cases where an intermediate process, much like
> > the service daemon was intended to be, is the most prudent
> > approach. Our expectation is that the overhead and complexity
> > of a "man in the middle" will be sufficient to demonstrate the
> > wisdom of changing the service programs instead.
> > As always, the Intel and Samsung security teams are more than
> > happy to help work out how best to address the unique and
> > critical needs of the service programs you are working with.
> > Thank you.
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev