[Dev] Cynara

Patrick Ohly patrick.ohly at intel.com
Mon Apr 14 14:30:05 GMT 2014


On Mon, 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.
>
> Every application with its data folders should be Smack labeled. Smack 
> labels are added in installation process for all applications: web, 
> native, etc.
> 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.
> 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.
> 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.
> - 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.

I have seen that and I still don't understand it. I asked explicitly for
instructions how SMACK is supposed to be used to protect service-level
data (see my initial mail in this thread), and so far no-one has been
able to answer that. If the answer is in
https://wiki.tizen.org/wiki/Security:SmackThreeDomainModel then I fail
to see it.

Jose answered with the launcher idea, but that isn't the "officially
blessed" solution, is it?

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