[Dev] Cynara

Lukasz Wojciechowski l.wojciechow at partner.samsung.com
Mon Apr 14 13:09:38 GMT 2014


Hello everyone.
I have an impression that discussion went some wrong place. Is this 
thread still about Cynara?
I'll try to answer inline to Cynara related questions. Please feel free 
to start new threads on other topics. ;)

W dniu 2014-04-11 01:21, Carsten Haitzler (The Rasterman) pisze:
> On Thu, 10 Apr 2014 16:06:36 +0000 "Schaufler, Casey"
> <casey.schaufler at intel.com> said:
>
>>> -----Original Message-----
>>> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
>>> Sent: Thursday, April 10, 2014 2:05 AM
>>> To: Schaufler, Casey
>>> Cc: José Bollo; dev at lists.tizen.org; Lukasz Wojciechowski
>>> Subject: Re: [Dev] Cynara
>>>
>>> On Wed, 2014-04-09 at 16:34 +0000, Schaufler, Casey wrote:
>>>>> On Wed, 2014-04-09 at 15:13 +0200, José Bollo wrote:
>>>>>> On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote:
>>>>>> You are right: apps not launched, not receiving the treatment have
>>>>>> full accesses. But to my eyes it is not a problem because:
>>>>>>   - Tizen enforces the use of launcher (for security) so what are the
>>>>>> applications that aren't launched?
>>>>> Which Tizen profile do you refer to here?
>>>>>
>>>>> In Tizen IVI there are several user processes which do not get spawned
>>> by
>>>>> the launcher and thus have access to more data than they really need.
>>>> Those are mostly services (weston, murphyd) and basic
>>>> UI applications (weekeyboard). Everything on Tizen (true
>>>> for Android, too BTW) has access to more data than it needs.
>>>> The question is whether it has access to data that matters.
>>>> Who cares if it can read /etc/tizen-release?
>>> I guess it depends on the data and the goals. I'd certainly would be
>>> more comfortable with a Tizen device where Weston, murphyd and
>>> weekeyboard can't read or (worse) write my PIM data.
>> What is "PIM data"?
>>
>> You are already trusting weekeyboard with your passwords
>> and weston with everything you display. If no one is making sure
>> that these programs are worthy of trust we have much bigger
>> problems than murphyd getting an accidental peek at your
>> "PIM data".
> yup. that was my point. there is a level of trust placed in such core
> apps/servers/tools - like we trust the kernel, or systemd, glibc etc. not to be
> malicious. it means that any bug in such core services should be taken
> seriously and fixed (bugs that could lead to compromising the functionality
> and turning a friendly tool into a malicious one).
>
> there is no point having some false sense of security.
Cynara can be used for privilege checking by services. Service is a 
process that can directly access some resource. If service wants to 
constrain access to provided resources it can ask Cynara as trusted 
service. If we want to restrict access to some resource:
1. access should be provided by a service not by a library
2. service should ask Cynara every time before granting access for some 
application

>>> Whether it's worth investing extra effort is up to the people defining
>>> the product and its requirements.
>> We have to live within the security budget. That means we can't
>> fix everything that's broken, we can't replace everything that's
>> hopelessly broken and we can't wrap everything with a protective
>> layer of magic that prevents good programs from doing bad things.
>> We can take steps, and isolating user installed applications is much
>> more important than anything else. Assuring that weekeyboard
>> and murphyd have absolutely minimal mutual access is just not
>> cost effective.
>>
>>>>>>   - DAC and MAC are still here filtering real intrusions
>>>>> But that doesn't help when the uid and smack label are the same.
>>>>>
>>>>>>> Regarding "leaving details of multi-threading to the integrator":
>>>>>>> that may simplify the work for the lib developer, but it complicates
>>>>>>> the usage of the lib for service developers, in particular if those
>>>>>>> services are not yet multithreaded. Just saying.
>>>>>> Agreed too. But remember only if it doesn't want to block.
>>>>> My expectation is that services will not be allowed to block. So either
>>> they
>>>>> are multithreaded, asynchronous or both. Cynara as currently designed
>>> does
>>>>> not fit into services which are asynchronous, but not multithreaded.
>>>> Do we have services that are asynchronous, but not multithreaded?
>>>> I'm all in favor of generality, but I don't believe in solving problems
>>>> that we don't have.
>>> As Jussi said, at least in the glib-based world, asynchronous without
>>> multithreading is the preferred model. If you need a specific example:
>>> syncevo-dbus-service, implementing the PIM Manager API in IVI, is not
>>> multithreaded.
>> OK, great, thank you. (Grumble)
For now we want to set up working Cynara ASAP. That is why there is only 
synchronous API available. However I agree that there is a great need 
for asynchronous API.
We do plan to provide one.
>>
>>> There's one more related issue with having a single blocking API
>>> function: suppose a service did create a thread to invoke that API and
>>> then while the check still runs needs to shut down cleanly, or (perhaps
>>> more realistic) the client asking for the restricted operation quits. A
>>> service must be prepared for this, even if it is only in the error
>>> handling paths. Can the service cancel the running call into Cynara?
>>>
>>> If it can't then it can only kill the thread, without knowing in which
>>> state that thread is.
>>>
>>> Cynara also needs to be thread-safe itself internally, of course.
>>>
>>> --
>>> Best Regards, Patrick Ohly
>>>
>>> The content of this message is my personal opinion only and although
>>> I am an employee of Intel, the statements I make here in no way
>>> represent Intel's position on the issue, nor am I authorized to speak
>>> on behalf of Intel on this matter.
>>>
>>>
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.tizen.org
>> https://lists.tizen.org/listinfo/dev
>
Best regards
Lukasz



More information about the Dev mailing list