[Tizen Application-dev] Executing shell command

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Mon Apr 2 01:04:05 GMT 2012


On Sat, 31 Mar 2012 16:50:21 -0700 Ryan Ware <ware at linux.intel.com> said:

> On 03/30/2012 08:41 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 30 Mar 2012 18:29:02 +0000 "Schaufler, Casey"
> > <casey.schaufler at intel.com>  said:
> >
> >>>> so you do care about "citizenship status".
> >> No, I don't care about emotionally loaded terms in a technical discussion.
> > i don't much care for people trying to avoid the topic by trying to change
> > what is a perfectly good summary/description, as this is precisely wat the
> > situation is, according to you. web apps are by design and intention never
> > going to be able to be as complete and useful as software that is native.
> > thus they are 2nd class. less powerful/capable. that is fact.
> That is true simply by the fact that they are running in a WRT.  It 
> doesn't matter what you do with the WRT, the environment will never be 
> the same as a native application and is never intended to be.  
> Otherwise, they wouldn't be writing in Javascript.

as there is no other officially supported way of doing 3rd party apps in
tizen, then that leads to "you won't be writing anything for tizen". and that
unfortunately leads to potential developers walking away and not becoming part
of the ecosystem. there are whole categories of applications unable to be
written. the original question has buried in it the desire to write such
classes of app. 

> >>>> you believe "apps" (web
> >>>> apps that have been downloaded and installed - a very 1970's concept
> >>>> there) should, in general, all be 2nd class citizens and never be
> >>> able
> >>>> to replicate the functionality of the core system.
> >> When you accepted the web app abstraction you had to agree to live
> >> within that abstraction. A shell environment provides facilities that
> >> are not constrained by adherence to the abstraction. As such it might
> >> be used to bypass the higher level implementation of the abstraction.
> > i never agreed to live within a web abstraction. i have no like for web
> > development, but its the only thing that tizen supports for 3rd party
> > development, so naturally developers will be most unhappy when they start
> > hitting roadblocks. i don't believe in neutering of developer freedom in
> > this way. neither do most open source developers i know.
> What you like or dislike in this area is irrelevant.  It is the stated 
> direction of Tizen and while you disagree with it, many Javascript 
> developers don't.

actually Tizen has no stated direction on this front. none at all.   if it
does, it's news to me that the direction is "3rd party apps will never have the
ability to replace the native apps, and will always be more limited".

> >>>> i.e. be a launcher,
> >>>> or task manager, or any one of many things that require access to
> >>>> things like /proc, or kill() or fork
> >>>> +exec() etc. :)
> >> Yes! You've got it! You're in an abstracted environment. Y'all asked
> >> for an abstracted environment. We're providing an abstracted environment.
> >> That means you don't get to do things that are inconsistent with the
> >> abstraction.
> > and as no alternative environment is supported, then this is the ONLY thing
> > people can do - and that is WHY people ask these questions.
> >
> >>> I tend to agree with Carsten here. An installed local web app should
> >>> behave no different than a native app.
> >>> It would be sandboxed as a normal native app.
> >>> So I don't see any security issues here, no more than what a native app
> >>> would bring.
> >> Even native apps are constrained to the abstraction of the environment.
> >> That is what makes native application support difficult. Providing the
> >> APIs for native apps is easy. Protecting the abstraction from the native
> >> apps is what's hard.
> > not hard at all, i you abstracted in the right way. ie put elements you
> > want to protect behind another uid and remote service (dbus/sockts etc.)
> If you abstracted in the right way?  The abstraction is already given to 
> us.  It's called HTML5.  That's what we live with.  If we could go ahead 
> and start with a brand new abstraction, we might be able to do that but 
> it's not the environment we live in.

it's what you implement BEHIND the js "api". do you simply implement all
security monoloithically inside the browser process? if your view is "we will
never have native apps" then who cares. browser can run as root as you simply
expect the browser process ITSELF to implement all security. hell. who needs a
kernel. we can just have it all be in "ring 0" and get some speedups.

reality is we don't go that far. we already separate off data, services etc.
into different layers - eg user -> root via service (dbus, socket etc.), we
separate process from eachother too. if you have data or a facility you wish to
protect from "general unconstrained use", you put it behind such a barrier.
e.g. - if you only want some apps that are "approved" to be able to access
contacts, you have contacts behind another uid, and a service (not a shared
file - though you could do it via uid's and groups, but now you only control
coarsely read & write).

if you have html5 app A and html5 app 5, then you only share the same "browser
process" if there are no security concerns between these 2 apps.

the html5 api only defines the binding layer. it does NOT define precisely how
you implement what is underneath. you implement the stuff underneath robustly
and securely (because if you don't, you can never have native apps if you wish
to extend your security policies to them too).

> >>> Could this be further explained? I mean what new security issues could
> >>> this bring into Tizen.
> >> It's nothing new. It's just the basic old notion of circumventing
> >> part of the system security facilities.
> >>
> >>> Note: we're not talking of web apps executed during a normal browsing
> >>> session.
> >>> We're talking about installed native web apps. If that concept is even
> >>> being considered.
> >> The security issues are pretty basic. The operating system kernel (Linux)
> >> enforces its version of security. The WRT enforces its brand as well. The
> >> WRT uses and takes advantage of the kernel security features, but in the
> >> end does a significant amount on its own. This is how is must be to support
> >> things like one-time access and controls based on such complex conceptual
> >> entities as "telephony". If you drop down below the abstraction in a shell
> >> you lose the ability to provide one-time access and the context to control
> >> telephony. Once we move all of that abstraction into the kernel (not
> >> happening any time soon) we will be able to allow shells on top of web
> >> apps. Until then, the price of the abstraction will include restrictions
> >> on the generality of the facilities available to the developer and the
> >> user.
> > i'd say wrong. if your telephony lives on the other side of a service (which
> > it should) you can make it one-time via that service (if it lives on another
> > uid). i assume here one-time means you get to do 1 "transaction" (e.g.
> > initiate 1 call). after that you re denied until re-authorized for that
> > connection. a connection gains initial authorization via system means
> > (telephony subsystem pops up a dialog requesting the user to are to allow
> > the app to make its call, being god, for 1 transaction). if can implement
> > many&  varied versions of this to (authorized for limited time, forever
> > (have to provide some kind of auth cookie/id), for the rest of your session
> > etc.)
> >
> > perfectly possible.
> >
> I think this shows a lack of appreciation for the security issues 
> involved in Web Apps.

system(cmd) {
  if (app.installed && app.allowed.system) return system(cmd);
  else return -1;
}

the original question was one of if going out to shell will ever be allowed.
indeed once you can do that you can do anything a native app can do. you don't
violate the security abstraction at all, *IF* you allow "going out to
shell" (another question floated about was the ability to write native modules
for performance or other reasons and extend js in html that way - which is the
same thing really. you're off at the same security level as a native app). the
web runtime can simply disallow any of these "exit points" unless the app is
authorized. ie it is granted the same status as a native application. this of
course means it must have its own process id - maybe its own uid, etc. etc.

> The bottom line is that allowing shell access for web apps would 
> invalidate many of our security requirements.  If we want to revoke all 
> of those security requirements, I don't have a problem with that and it 
> will make my life much easier.  However, since those requirements do 
> exist and I'm responsible to ensure we don't violate those requirements, 
> we won't be implementing shell access for web apps.

all of the arguments against such a "system()" api in js are based on the
assumption that it can ONLY be done in a totally unrestricted way
ie:

system(cmd) {
  return system(cmd);
}

as opposed to:

system(cmd) {
  if (app.installed && app.allowed.system) return system(cmd);
  else return -1;
}

this 2nd case doesn't add any insecurity as long as app is not installed
(remote web page) OR the app has never been "allowed" to do this (via some
approval mechanism - at installation, or at runtime etc.). you are still more
secure than a native app as you still are unable to escape the js sandbox
without the additional "allowed" flag. once you've escaped - it's the same as a
native app though. so i don't see how this is a problem, unless you never want
to have any native apps, thus never have any layer to escape the js sandbox
ever as the native domain is totally disallowed for 3rd parties.

-- 
Carsten Haitzler (The Rasterman) <tizen at rasterman.com>


More information about the Application-dev mailing list