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

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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Reply via email to