[Dev] Cynara

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

> -----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.
The application, we'll call it A, is downloaded and installed at the user's
request. The user invokes A using the launcher. The launcher looks at
the information about A that the installer provided, including the Smack
label to run A with (perhaps App::A), sets all the appropriate attributes, and starts A.

All applications are going to need to communicate with the System domain,
so they need to be granted access to do so:
	App::A System w
	System App::A w
in the Smack rules.

But that isn't sufficiently fine granularity for W3C. A service may offer more
than one "privileged" operation on a socket. Our service S, which understands
that some of what it provides requires the client have privilege, has to make
the decision. S asks Cynara about A (using the Smack label App::A as an identifier.
Cynara looks at what the installer told it, and tells S. S has to know to call Cynara.

So, the service data maintained by S is not readable by A. A can talk to S, and S
can talk back. S makes its own decisions about what to tell A based on what
Cynara tells S.

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.

If the question is "how do I protect service S from service Q",
the answer is that the packages we've chosen to compose Tizen
have an amazing set of interactions and in many cases isolation
is not only impractical but counter to the design intent of the service.
Proper isolation of S from Q is going to take work that we probably
don't have the time for in Tizen 3. 

> 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