[Dev] Understanding Cynara scope.
casey.schaufler at intel.com
Wed May 14 16:39:21 GMT 2014
> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Wednesday, May 14, 2014 8:34 AM
> To: Schaufler, Casey
> Cc: Rafał Krypa; dev at lists.tizen.org; Oda, Terri
> Subject: Re: [Dev] Understanding Cynara scope.
> On Wed, 2014-05-14 at 15:16 +0000, Schaufler, Casey wrote:
> > > -----Original Message-----
> > > From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> > > Sent: Wednesday, May 14, 2014 12:24 AM
> > > To: Schaufler, Casey
> > > Cc: Rafał Krypa; dev at lists.tizen.org; Oda, Terri
> > > Subject: Re: [Dev] Understanding Cynara scope.
> > >
> > > On Tue, 2014-05-13 at 21:44 +0000, Schaufler, Casey wrote:
> > > > The Smack label of the task executing the application code
> > > > (be it a plugin, separate executable or some other mechanism)
> > > > must be set to the label assigned to that application. Once this
> > > > is accomplished the services that use Cynara to make application
> > > > access checks have the information they need to do so. Crosswalk
> > > > need only set the process Smack label before invoking the
> > > > application.
> > >
> > > This assumes that Crosswalk runs a separate process for each
> > > application, doesn't it? That assumption has pretty much been shown to
> > > not hold.
> > You can't seriously be suggesting that TwitterBirds and
> > BankOfElbonia run in the same thread at the same time.
> I'm just repeating what was explained by Baptiste and confirmed by Xu in
> the "enforcing priviliges of web apps" mail thread. Originally it was
> Dominig who mentioned this design. And yes, my understanding currently
> is that at least some operations done for TwitterBirds and BankOfElbonia
> run in the same process at the same time.
There are services provided to the applications by crosswalk
that come from the same process, but the applications themselves
have to be in separate threads.
> I'm not in the Crosswalk team and wasn't involved in any of the
> discussions leading to this design.
Probably just as well, all things considered.
> > > Can someone explain the details and come up with the necessary
> > > patches? Perhaps it's simple technically, but if no-one can do that for
> > > other reasons (perhaps because he or she has no time), then it is a hard
> > > problem for the project.
> > I'm sorry, but there is more going on here than we're
> > going to fix on a mailing list. We need to sit down with the
> > code and figure out what you have done.
> You mean the Crosswalk team here and not me, right?
Yes. Well, maybe you too, but separately.
> > The questions
> > you are asking are scaring me a little. I understand that
> > Crosswalk is a sophisticated system in its own right. There
> > is no way to address some of what you're asking without
> > understanding what you're trying to accomplish.
> My personal goal is merely to understand how security will work, because
> as maintainer of a sub system which has confidential data (contacts) I
> need to do the work that is expected of me.
Crosswalk is a terrible example to use for learning about
how security should be done. Most services are much simpler.
> If no-one has asked these questions before, then it's about time that
> someone does. But as you said, don't panic ;-}
> 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