[Dev] Cynara

José Bollo jose.bollo at open.eurogiciel.org
Wed Apr 9 10:27:17 GMT 2014

On mer, 2014-04-09 at 09:30 +0200, Patrick Ohly wrote:
> 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...

Yes that is really interesting. (I liked the polish name of karczoch but
cynara is also good, bravo...)

I'm sharing many things of what you wrote. And I already started some
evaluation of the same architecture. Then i already have some code but
i'm thinking that you too. I would be happy to share it soon with all of
you. How to coordinate?

Patrick pointed out some problems. I'm commenting below what he wrote.

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

I really agree with that remark. That is why I proposed a launcher that
is aware of the problem of sharing/not sharing the filesystem.
(see https://lists.tizen.org/pipermail/dev/2014-April/002292.html)
I think that because smack rules modification will become lighter, the
launch time will be less than 1 ms.

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

That is a good idea. Can you estimate how hard it will be? I'm afraid
that it could be complicated.

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

IMHO it should block and be "as if mono thread". It would simplify the
development process of the library, leaving details of multi-threading
to the integrator. It would be very painful to launch a thread to wait
some answer or to provide a file descriptor for the glib loop, the qt
loop, the ??? loop ....

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

Reading the wiki page, I understood that the privilege is one of the
privilege defined here https://www.tizen.org/fr/privilege/ Your remark
is interesting but it will have deep implications on the complexity of
cynara if the "dynamic" rules are chosen to be implemented. IMHO it have
to be kept simple.

Best regards

More information about the Dev mailing list