[Dev] Cynara

Carsten Haitzler c.haitzler at samsung.com
Wed Apr 16 02:12:23 GMT 2014



On 04/16/2014 03:25 AM, Schaufler, Casey wrote:
>> -----Original Message-----
>> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Carsten
>> Haitzler
>> Sent: Monday, April 14, 2014 6:59 PM
>> To: dev at lists.tizen.org
>> Subject: Re: [Dev] Cynara
>>
>>
>>
>> On 04/15/2014 10:16 AM, Schaufler, Casey wrote:
>>>> -----Original Message-----
>>>> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Carsten
>>>> Haitzler
>>>> 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.
>>
>> 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. 

then the documentation is not great. if client == smack label... the
docs should say this. :)

>  
>>>> 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) <tizen at rasterman.com>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> Dev at lists.tizen.org
>>>> https://lists.tizen.org/listinfo/dev
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at 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.
> 
> 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140416/046b8791/attachment.asc>


More information about the Dev mailing list