[Dev] Cynara

José Bollo jose.bollo at open.eurogiciel.org
Wed Apr 9 13:13:03 GMT 2014

On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote:
> On Wed, 2014-04-09 at 12:27 +0200, José Bollo wrote:
> > On mer, 2014-04-09 at 09:30 +0200, Patrick Ohly 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.
> I've seen that. With that approach, apps can be restricted, but process
> not getting that treatment would still have full access to everything. I
> wonder whether we can do better than that.

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?
 - DAC and MAC are still here filtering real intrusions
 - the policy for the user will be applied anyway
 - there is a need for full access (a file browser for exemple,
developper tools)
 - why to disable something that would be enabled after validation (okay
malicious code but config let you choose to automatically accept keys)
 - letting someone scrunch its own data is a freedom act
 - in worst case, a binfmt stuff could enforce launcher

> Regarding the launcher, does it still grant the restricted app access to
> the system and session D-Bus? Can it reduce access rights for files
> and/or directories from "read/write" to just "read"? That would be
> important for the "fast read-only access, secure and controlled write"
> use case.

Yes the launcher allow to hide parts, to make read-only other parts and
to grant read/write accesses to other part. Any combination is possible,
the given example is:

 -     /home                          -- dont see any other user
 +rw   /home/%user/.config/%appid     -- access to config
 +r    /home/%user/share              -- shared data
 +rw   /home/%user/share/%appid       -- own shared data
 +rw   /home/%user/share/.cert/%cert  -- same certificate

What means that no other user home is visible (- /home), no data of the
user are visibles except the config directory of the application (r/w),
the data shared by applications, read only except for owned data and
data sharing the same certificate.

> > > 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.
> I've no idea. I'm just bringing it up as a wish-list item ;-}
> > > 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 ....
> Isn't glib the de-facto common standard? Qt on desktops is compiled with
> glib integration support. I've seen that EFL also has code for it. I
> don't know how either of these get compiled for Tizen, though.

Agreed halas. But I saw in
https://wiki.tizen.org/wiki/Security:Cynara:ApplicationCredentials that
dbus over libdbus, kdbus and 0MQ are also targeted.

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

Best regards

More information about the Dev mailing list