casey.schaufler at intel.com
Thu Apr 10 16:06:36 GMT 2014
> -----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
> > > 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"?
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
> 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
> > > > - DAC and MAC are still here filtering real intrusions
> > >
> > > But that doesn't help when the uid and smack label are the same.
> > >
> > > > > Regarding "leaving details of multi-threading to the integrator":
> > > > > that may simplify the work for the lib developer, but it complicates
> > > > > the usage of the lib for service developers, in particular if those
> > > > > services are not yet multithreaded. Just saying.
> > > >
> > > > Agreed too. But remember only if it doesn't want to block.
> > >
> > > My expectation is that services will not be allowed to block. So either
> > > are multithreaded, asynchronous or both. Cynara as currently designed
> > > not fit into services which are asynchronous, but not multithreaded.
> > Do we have services that are asynchronous, but not multithreaded?
> > I'm all in favor of generality, but I don't believe in solving problems
> > that we don't have.
> As Jussi said, at least in the glib-based world, asynchronous without
> multithreading is the preferred model. If you need a specific example:
> syncevo-dbus-service, implementing the PIM Manager API in IVI, is not
OK, great, thank you. (Grumble)
> There's one more related issue with having a single blocking API
> function: suppose a service did create a thread to invoke that API and
> then while the check still runs needs to shut down cleanly, or (perhaps
> more realistic) the client asking for the restricted operation quits. A
> service must be prepared for this, even if it is only in the error
> handling paths. Can the service cancel the running call into Cynara?
> If it can't then it can only kill the thread, without knowing in which
> state that thread is.
> Cynara also needs to be thread-safe itself internally, of course.
> 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