[Dev] Cynara

Patrick Ohly patrick.ohly at intel.com
Wed Apr 9 07:30:53 GMT 2014


On Tue, 2014-04-08 at 20:57 +0200, Lukasz Wojciechowski wrote:
> 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.

Interesting, thanks for sharing. A few questions, if I may...

Access control: I understand that a service will have to implement this
access control mechanism and I see how Cynara will help with this. What
hasn't become clear to me is how a service running as a normal user
process (same PID as all other apps of the user) will be able to protect
its data files from those other processes when using the 3-domain Smack
model. Can someone point me towards documentation for that, ideally with
an example? Will it be possible to write services that grant direct
read-only access to files (for performance reasons) while handling
writes in the service?

API + upstream: getting patches depending on Cynara into upstream
projects might be hard, depending on the project and how tolerant they
are of ifdefs. Would it be possible to provide a compat layer that acts
like Polkit but underneath calls Cynara? It doesn't have to be ABI
compatible to the GObject API, some limited API compatibility might be
good enough to get upstream code compiled on Tizen.

Cynara API: you mention a single API function. Will that be synchronous
or asynchronous? If synchronous, how are services expected to remain
responsive will a policy check runs? Multithreading? My main concern is
a policy check which involves the authentication agent and thus user
interaction; normal policy checks probably will be fast (but still...).

Policies: <Application context, Privilege> - how is the "privilige"
defined? Does it have to be static (like "access contacts") or can it be
dynamic (like "access address book 'foo'", where 'foo' was created
sometime by the user)? Based on the description of the policy types it
looks like privileges will be fairly static.


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





More information about the Dev mailing list