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 <[email protected]> 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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
