[Tizen Application-dev] Executing shell command

Aniello Del Sorbo anidel at gmail.com
Fri Mar 30 09:13:21 GMT 2012


On Fri, Mar 30, 2012 at 01:06, Carsten Haitzler <tizen at rasterman.com> wrote:
> 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. :)
>

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.

Could this be further explained? I mean what new security issues could
this bring into Tizen.
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.

Aniello


More information about the Application-dev mailing list