[Tizen Application-dev] Executing shell command
casey.schaufler at intel.com
Fri Mar 30 18:29:02 GMT 2012
> -----Original Message-----
> From: Aniello Del Sorbo [mailto:anidel at gmail.com]
> Sent: Friday, March 30, 2012 2:13 AM
> To: Carsten Haitzler
> Cc: Schaufler, Casey; application-dev at lists.tizen.org
> Subject: Re: [Tizen Application-dev] Executing shell command
> On Fri, Mar 30, 2012 at 01:06, Carsten Haitzler <tizen at rasterman.com>
> > 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
> >> 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
> >> 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
> >> 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
> >> 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".
No, I don't care about emotionally loaded terms in a technical discussion.
> > 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
> > 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.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
> 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.
> 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
> 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.
More information about the Application-dev