[Tizen Application-dev] Executing shell command

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Fri Mar 30 00:06:43 GMT 2012


On Thu, 29 Mar 2012 17:07:53 +0000 "Schaufler, Casey"
<casey.schaufler at intel.com> said:

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

so you do care about "citizenship status". 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. 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. :)

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


More information about the Application-dev mailing list