[Dev] Cynara

Schaufler, Casey casey.schaufler at intel.com
Mon Apr 14 21:03:01 GMT 2014


> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Monday, April 14, 2014 12:13 PM
> To: Schaufler, Casey
> Cc: Lukasz Wojciechowski; Carsten Haitzler (The Rasterman);
> dev at lists.tizen.org
> Subject: Re: [Dev] Cynara
> 
> On Mon, 2014-04-14 at 15:40 +0000, Schaufler, Casey wrote:
> > > -----Original Message-----
> > > From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> > > Sent: Monday, April 14, 2014 7:30 AM
> > > To: Lukasz Wojciechowski
> > > Cc: Carsten Haitzler (The Rasterman); Schaufler, Casey;
> dev at lists.tizen.org
> > > Subject: Re: [Dev] Cynara
> > >
> > > 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.
> >
> > Let's see if I can address the question.
> >
> > The service, which I'll call S for convenience, runs in the System domain.
> 
> [...]
> 
> I think I already understood that part.
> 
> But my question was about normal services, running in the user domain.
> According to the three domain model Wiki page, "system domain is
> comprised of the basic system services" and "user domain is comprised of
> the services that interact directly with the person using the Tizen
> system and the data those services".

Most services won't be in the User domain, they will be in the
System domain. Things like the display service are in the User
domain because they pretty much have to be.

 > Every person gets his or her own address book, so contact-service would
> be one example of such a service. The data will (eventually) end up in
> $HOME. Is there going to be some kind of protection against accidental
> or malicious file access from apps also running in the user domain?

Well, you're making some assumptions that may or may not be
valid. The contact service, using buxton, could easily be a system
service running safely in the System domain. The data would never
go into $HOME, it would be safely stored in the buxton database.
If there is an instance of the address book per user, in the User domain,
it can still use buxton. Of course, you could store the information in
$HOME. The question then becomes what access an App needs to
$HOME. Why should the App have access to $HOME? Each App will
have a directory for its private data. There will be pre-defined directories
to meet the sharing requirements, and those won't be $HOME.

 
> > Perhaps the confusion comes from the name "three domain model".
> > We're not talking a lot about the labeling of applications because the
> > details of how Crosswalk and WRT are interacting with the installer
> > are still in flux. We can say for certain that user installed applications
> > will be running with their own Smack labels. They will have only the
> > access to the System and User domains required.
> 
> This part is what needs specific examples and more information. Is it
> true what Rafał Krypa said, that each app will get its own Smack?

Yes.

> I suppose that would be *instead* of "User", not in addition to it?

Yes. You only get one Smack label at a time.

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