[cap-talk] A couple notes on Palm webOS security

Rob Meijer capibara at xs4all.nl
Thu Jul 2 03:40:18 EDT 2009


On Thu, July 2, 2009 06:06, Steve Witham wrote:
> These are from my ph file of random info, sorry for the format.
> webOS apps are basically Javascript web pages running in a
> specialized browser.
>
>>Both Contacts and Calendar will allow applications to add
>>information that will get merged into an integrated view.
>>They don't allow applications to read, delete or update
>>any data that wasn't created by the same application.
>
> Reading between the lines it sounds like each app may have a
> Linux user id.

Possible, or alternatively a filesystem implementing a view based
access control mechanism. In MinorFs I use a similar mechanism, however
avoiding the per application view, and providing only a per non-persistent
process view and a per pseudo-persistent process view. The reason I
avoided implementing the per application view is that it is equivalent to
how languages like C++ provide the construct of static class level
variables, of what we know that it encourages the use of
undeniable/implicit authority
(that until recently I mistakingly used to call ambient authority, tnx
Mark/Alan). I have been arguing that providing a mechanism for
constructing undeniable/implicit authority in such a way, is a form of
hiding and dampening the problem of the single global namespace filesystem
access, while the pid and pppid approach, although a bigger leap for
architects and developers, does solve the problem in a structural way. I
argued that providing a mechanism for partially hiding the underlaying
problem may actually be harmful.

I've been getting multiple comments that I am being a bit to purist about
this, that a per application (per application uid combination to be
precise) view would be useful for MinorFs to provide, and that providing a
way to take a small but easy step forward may be more fruitful than
providing a way to take a bigger step forward that is harder to take.

It would be absolutely trivial to implement and add the above described to
MinorFs, I am however currently not quite sure if it would be useful or
harmful or both.

Rob



More information about the cap-talk mailing list