[Tizen Application-dev] Executing shell command
casey.schaufler at intel.com
Thu Mar 29 17:07:53 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: Monday, March 26, 2012 5:30 PM
> To: Pierce, Dean E
> Cc: application-dev at lists.tizen.org
> Subject: Re: [Tizen Application-dev] Executing shell command
> On Mon, 26 Mar 2012 11:34:24 -0700 "Pierce, Dean E"
> <dean.e.pierce at intel.com>
> > My first thought :
> > "Oh god I hope not."
> > My second thought:
> > "Wouldn't that be insane if someone actually did that?"
> > My third thought:
> > "I really hope someone isn't in their cube right now trying to
> > implement this as a surprise feature for the next release."
> > terrifying idea. Microsoft tried it once, and they are still trying
> > to get that monster back in the box (ActiveXObject('WScript.Shell')).
> > Remember that the nature of HTML allows attackers to create new
> > iframes in arbitrary uncontrolled contexts. There are multiple ways
> > for attackers to impersonate domains and assume the rights of various
> > applications. If my talk at the tizen conference gets accepted, I
> > will be talking about this in detail.
> actually it depends. if you have locally installed "web apps", then
> this would allow the app to be a first-class-citizen along with the
> abilities of native apps. this js function would ONLY work if your app
> was installed locally (and had appropriate security clearance - e.g. on
> install it requested such capabilities and you agreed). as such the
> intent of using html5 for apps is to have them work and behave like
> native apps would.
Dean's initial reaction is correct, and I shared his third thought.
It would be criminal in some countries to provide shell access as
a web app. The web app environment has, with malice aforethought,
distanced itself from the user based security environment that makes
shell access viable on traditional (stone knife and bear skin) user
interfaces. It is not possible to reintroduce the protections
provided by the underlying OS on top of the web app infrastructure.
You have lost the context, information and most importantly the
chain of trust required to provide a general purpose shell interface.
Part of the deal that exists between OS developers and application
runtime developers is that once the application runtime starts to
make its own security policy decisions it does not get to expect that
the underlying OS is going to magically be able to protect from the
consequences of those decisions. The obvious example for a shell is
what userid to run it with. Clearly you don't want it to be root*
or the uid that the web app support environment runs with**. You're
on a bleeping telephone or TV set, not a 1970's multiuser system
with individual accounts. Do you want a special shell userid?
Are you going to put up a prompt for each shell command executed,
asking if it's OK for the program to use stat(2), open(2), read(2),
... ? How do you propose we protect the "resources" managed by the
Application environment at the syscall level***? Unless resources
are defined strictly in terms that can be translated into OS
primitives you can't throw away the abstraction introduced by the
web app environment.
No. I don't give a rat's pittutte about the citizenship status
of a web app. The notion is completely flawed from a security
perspective and has no place on an environment that is connected
to any network, public or private.
* I hope this is obvious.
** This should be obvious, too. If not, read the rm(1) man page.
*** There is some protection we can provide with system access controls,
Smack in the Tizen case. However, resources are being defined in ways
that challenge even the most flexible access control schemes.
> Carsten Haitzler (The Rasterman) <tizen at rasterman.com>
> Application-dev mailing list
> Application-dev at lists.tizen.org
More information about the Application-dev