> -----Original Message----- > From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten > Haitzler > Sent: Monday, April 14, 2014 6:59 PM > To: dev@lists.tizen.org > Subject: Re: [Dev] Cynara > > > > On 04/15/2014 10:16 AM, Schaufler, Casey wrote: > >> -----Original Message----- > >> From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten > >> Haitzler > >> Sent: Monday, April 14, 2014 4:47 PM > >> To: Lukasz Wojciechowski > >> Cc: dev@lists.tizen.org > >> Subject: Re: [Dev] Cynara > >> > >> On Tue, 08 Apr 2014 20:57:37 +0200 Lukasz Wojciechowski > >> <l.wojciec...@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. > > yeah - i know this one. this is how you can get pid/uid/gid from the other end > of a unix socke. how do you get the client and client_session string (in a way > that the client can't lie to you)?
SO_PEERSEC gets you the Smack label. Since every Application gets a unique Smack label at installation time the Smack label can be used to identify the Application. It would be better if we had an explicit AppID that was independent of Smack, but there are kernel constraints that make that infeasible. > >> if these are provided by the client... a client can just lie. > > > > You're correct. > > > >> 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 you use to categorize a client). > > > > This is one of the methods available. There are race conditions in > > /proc, so it isn't technically reliable. > > sure. interestingly the cynra wiki suggests using proc to get creds: > > https://wiki.tizen.org/wiki/Security:Cynara:ApplicationCredentials > > i would expect to tell peolpe to only use socket+ SO_PEERCRED only it is > reliable. > > >> > >> -- > >> Carsten Haitzler (The Rasterman) <ti...@rasterman.com> > >> _______________________________________________ > >> Dev mailing list > >> Dev@lists.tizen.org > >> https://lists.tizen.org/listinfo/dev > > _______________________________________________ > > Dev mailing list > > Dev@lists.tizen.org > > https://lists.tizen.org/listinfo/dev > > > > -- > The above message is intended solely for the named addressee and may > contain trade secret, industrial technology or privileged and confidential > information otherwise protected under applicable law including the Unfair > Competition Prevention and Trade Secret Protection Act. Any unauthorized > dissemination, distribution, copying or use of the information contained in > this communication is strictly prohibited. If you have received this > communication in error, please notify the sender by email and delete this > communication immediately. _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
