[Dev] Cynara

José Bollo jose.bollo at open.eurogiciel.org
Tue Apr 15 14:07:59 GMT 2014

My apologies for the short answer of yesterday. I had to go to dentist
and couldn't go into details.

On lun, 2014-04-14 at 16:07 +0200, Lukasz Wojciechowski wrote:
> W dniu 2014-04-14 15:44, Patrick Ohly pisze:
> > On Mon, 2014-04-14 at 15:09 +0200, Lukasz Wojciechowski wrote:
> >> I have an impression that discussion went some wrong place. Is this
> >> thread still about Cynara?
> > The display server aspect is going a bit far, but I still think that it
> > is relevant for assessing Cynara to understand how the rest of the
> > problem is going to get addressed (or not addressed).
> >
> > It was not said clearly at the beginning which apps will be denied
> > access via Cynara, and how said apps will be prevented from accessing
> > data handled by the service.
> >
> > In my current understanding, Cynara is targeted at web apps which run
> > inside a controlled environment already (the web runtime) and can only
> > access the host through these services. That Cynara checks will also be
> > applied for native system apps is a side effect that we won't take
> > advantage of at the moment, because these apps can already do anything
> > they want to the users data anyway. Note that I am thinking of the PIM
> > data case here where service and app both run using the user's uid; it
> > may be different for more privileged and/or special services.
> >
> > Is that correct?
> >
> I think apps cannot do anything they want with user data. Even native 
> apps have access only to their private data.

Yes it is the case of many applications. But there are also many
applications that are collaborating. Think about libre-office,
pdf-reader, photos, videos, ...

Some application should also have full access. For example the file
browser. (Yes, I installed it on my android phone and it is really

> Every application with its data folders should be Smack labeled. Smack 
> labels are added in installation process for all applications: web, 
> native, etc.

With Tizen 2, Webapps was launched using a link. Setting Smack context
isn't possible with links (what is good 8) I suppose that for this
reason, there is a need for a launcher to setup the smack context.

> Different Smack labels for apps give us Smack level separation.
> Consider what Rafał Krypa <r.krypa at samsung.com> wrote:
> One assumption for Smack is needed for this model to work:
>  to assign separate Smack labels for the applications.
>  I believe that there is a consensus to go that way.

It is not obvious. I were thinking that the security model of Tizen 2
was swept away but I'm discovering that it is still here. I'm not seeing
a big difference. Except that there is now a service for the permissions
that can't be handled by smack.

> While different, the app labels would still logically
>  belong to the User domain. This is probably very confusing,
>  given the "3-domain policy" name, but a domain is defined
>  as a set of labels.

That is becoming the 3 prefixes policy.

> Separate Smack labels offer two important benefits:
> - separation: keeping private application files private,
>  hidden from other apps. This also prevents stuff like ptrace()
>  between applications with different privileges.

Using namespaces is IMHO more efficient because you don't spend any time
to check (with long set of rules) the files that aren't accessible at

For ptrace, you are right. It will implies that a debugger application
will have to get accesses to applications it is debugging.

> - identification: whether a service consults Cynara for policy
>  or implements some policing on itself, it must be sure who is
>  on the other side. Smack label is a perfect unforgeable identifier
>  for user apps.

It also have drawbacks:
 - how many smack rules have to be added for each new application? The
problem is in O(N²). How does it scale?
 - will you used the application ids, the hash code? That is not human
 - it complicates the collaboration of the applications and the sharing
of data.
 - it also may have the side effect to enforce use of super powers to
violate security.
 - the peoples that are used to LINUX will be lost and surely

Best regards

More information about the Dev mailing list