[Dev] Cynara

Schaufler, Casey casey.schaufler at intel.com
Thu Apr 10 19:15:08 GMT 2014


> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Thursday, April 10, 2014 11:24 AM
> To: Schaufler, Casey
> Cc: José Bollo; dev at lists.tizen.org; Lukasz Wojciechowski
> Subject: Re: [Dev] Cynara
> 
> On Thu, 2014-04-10 at 16:06 +0000, Schaufler, Casey wrote:
> > > -----Original Message-----
> > > From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> > > Sent: Thursday, April 10, 2014 2:05 AM
> > > To: Schaufler, Casey
> > > Cc: José Bollo; dev at lists.tizen.org; Lukasz Wojciechowski
> > > Subject: Re: [Dev] Cynara
> > >
> > > On Wed, 2014-04-09 at 16:34 +0000, Schaufler, Casey wrote:
> > > > > On Wed, 2014-04-09 at 15:13 +0200, José Bollo wrote:
> > > > > > On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote:
> > > > > > You are right: apps not launched, not receiving the treatment
> > > > > > have full accesses. But to my eyes it is not a problem because:
> > > > > >  - Tizen enforces the use of launcher (for security) so what
> > > > > > are the applications that aren't launched?
> > > > >
> > > > > Which Tizen profile do you refer to here?
> > > > >
> > > > > In Tizen IVI there are several user processes which do not get
> > > > > spawned
> > > by
> > > > > the launcher and thus have access to more data than they really
> need.
> > > >
> > > > Those are mostly services (weston, murphyd) and basic UI
> > > > applications (weekeyboard). Everything on Tizen (true for Android,
> > > > too BTW) has access to more data than it needs.
> > > > The question is whether it has access to data that matters.
> > > > Who cares if it can read /etc/tizen-release?
> > >
> > > I guess it depends on the data and the goals. I'd certainly would be
> > > more comfortable with a Tizen device where Weston, murphyd and
> > > weekeyboard can't read or (worse) write my PIM data.
> >
> > What is "PIM data"?
> 
> Personal information management. In my definition that's primarily contacts,
> events, tasks and notes. Sometimes email is also included.

Thanks. My acronym processor died in 1992.

The big issue I have is that, while I can do something about PIM
(or any sort of) data, I can't do anything about *abstract* PIM
data. We have access controls on IPC and on containers, but not
on the data itself. Identifying the things we can control as
opposed to the abstractions we like to talk about is the task.

 
> > You are already trusting weekeyboard with your passwords and weston
> > with everything you display. If no one is making sure that these
> > programs are worthy of trust we have much bigger problems than
> murphyd
> > getting an accidental peek at your "PIM data".
> 
> Weston was a bad example and digressed (as far as I am concerned - I'm sure
> Jussi disagrees ;-) into (admittedly interesting) discussion of how to
> communicate reliably with components in the system.

Weston is one of the cases where you can demonstrate that it is
a prime example either argument.

> My main concern is about the other, less privileged processes that currently
> get started such that they can access everything although they don't need to.

That's a small matter of economics. We can invest in cleaning up these
programs to make them less vulnerable to attack and we can craft
the access controls around them to restrict them more. It costs time
and money to do so.

> If Tizen is going to treat system apps (for example: the Lemolo dialer in IVI)
> like third-party apps from an app store, then that concern gets addressed
> sufficiently well. If not, then I think we should reconsider that approach.

No. Third party apps from the app store are going to be isolated.
That is one thing everyone agrees on. That's the whole reason that
we need Cynara, so that the abstract "privileges" these apps are required
to be allowed can be managed.

> Saying "these are trusted apps, we don't need to control them" doesn't fly
> for me. Shit happens, so the less damage these apps can do when it happens
> the better. This doesn't even have to be an exploit.
> Accidentally erasing or trashing an important file would also be bad.

If we had the funds to fix the crap, believe me, we would.
The economics require we use packages with flaws. There is
no such thing as aftermarket security, and the SELinux experience
demonstrates that. You don't get security by restricting a program
to doing what the program does without looking to see if that is
a good thing.

> But of course that doesn't come for free, so I can accept the argument
> "these are trusted apps, we've done as much as we could in our limited time
> to make them reliable, further effort is better spent elsewhere".

Yeah, that's the nut of it.

> > > Whether it's worth investing extra effort is up to the people
> > > defining the product and its requirements.
> >
> > We have to live within the security budget. That means we can't fix
> > everything that's broken, we can't replace everything that's
> > hopelessly broken and we can't wrap everything with a protective layer
> > of magic that prevents good programs from doing bad things.
> > We can take steps, and isolating user installed applications is much
> > more important than anything else. Assuring that weekeyboard and
> > murphyd have absolutely minimal mutual access is just not cost
> > effective.
> 
> Fair enough.

Thanks. We try.

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