casey.schaufler at intel.com
Tue Apr 15 01:16:55 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Carsten
> Sent: Monday, April 14, 2014 4:47 PM
> To: Lukasz Wojciechowski
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Cynara
> On Tue, 08 Apr 2014 20:57:37 +0200 Lukasz Wojciechowski
> <l.wojciechow at partner.samsung.com> said:
> > Services that are being used by applications need to control if the
> > caller has sufficient privileges to call each API. In Tizen 2.2.X this
> > level of access control was done using very detailed Smack policy on IPC
> > mechanisms. Since Tizen 3.0 is introducing compact 3-domain Smack
> > policy, there is a need for user-space mechanism that complements the
> > solution. This is a place for new module - Cynara.
> > Details can be found at wiki page:
> > http://wiki.tizen.org/wiki/Security:Cynara
> > Page is still being constructed, but is is high time to share and
> > probably start a discussion.
> > I will be glad to answer any questions about it.
> > I plan to publish roadmap for Cynara development and API draft this week.
> cynara_check ... where will the service daemon get the client string, and
> client_session string?
SO_PEERCRED and SO_PEERSEC. Dependable. The wiki includes
examples of how to do it.
> if these are provided by the client... a client can just lie.
> why not just provide the PID of the client directly to cynara and it does
> the rest? (this also means you can change, in future, what parameters/info
> use to categorize a client).
This is one of the methods available. There are race conditions
in /proc, so it isn't technically reliable.
> Carsten Haitzler (The Rasterman) <tizen at rasterman.com>
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev