[Tizen Application-dev] Executing shell command

Schaufler, Casey casey.schaufler at intel.com
Mon Apr 2 15:56:20 GMT 2012


> -----Original Message-----
> From: application-dev-bounces at lists.tizen.org [mailto:application-dev-
> bounces at lists.tizen.org] On Behalf Of Carsten Haitzler
> Sent: Sunday, April 01, 2012 6:04 PM
> To: Ryan Ware
> Cc: application-dev at lists.tizen.org
> Subject: Re: [Tizen Application-dev] Executing shell command
> 
> 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.

Your conclusion that "you won't be writing anything for Tizen" is hardly
justified by the lack of a web API based shell. Perhaps you could
describe some of the applications in the class that you would be
prevented from writing.

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

You underestimate the abilities of HTML5 developers. As far as being
"more limited" goes you are looking at a tradeoff between the high
level abstractions that developers are clamoring for and the detailed
access that they are built on top of. The industry direction is pretty
clear, and it's in the direction of higher level abstractions. I am
myself a dinosaur and prefer less abstraction, which is why I work
providing the abstractions rather than building on top of them.


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

Yep. Not this release. Too much work for the short term.

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

Nope. What you need to protect is not "system()", but "exec()".

> 
> 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>
> _______________________________________________
> Application-dev mailing list
> Application-dev at lists.tizen.org
> https://lists.tizen.org/listinfo/application-dev


More information about the Application-dev mailing list