[cap-talk] Applications for a capability platform - PLASH discussion

[Jed Donnelley]

On 2/29/2008 9:49 AM, Jonathan S. Shapiro wrote:
> On Fri, 2008-02-29 at 09:27 -0800, Jed Donnelley wrote:
>> At 06:18 AM 2/29/2008, Jonathan S. Shapiro wrote:
>>> You are surely aware of PLASH,
>> Indeed, as PLASH has been often discussed on this list.  However,
>> I don't know what the issues are that PLASH faced with regard
>> to getting the GNU applications to run.  I'd be interested to
>> hear about those in more detail.  E.g. what fraction of
>> glibc can be adapted to run directly over a capability
>> infrastructure and what fraction requires "re-engineering"
>> at the application level.
> 
> As I understand it, PLASH proceeds by establishing a new file name space
> just prior to application start, and binding capabilities in the name
> space in a way that is consistent with the application's expectations
> and requirements.
> 
> The net effect of this is that the application is oblivious to the fact
> that it runs within a capability environment, and no "caplib" is
> required. A major point of PLASH is that application re-engineering is
> not required.

How do I run "chmod" under PLASH?

> That said, however, I think we can then start to look at hybrid
> solutions that would augment PLASH with things like a power box. These
> would require source-level modification of the applications or their
> runtime libraries (e.g. Gnome), but such modifications would be
> well-localized within the respective applications.

On 2/29/2008 10:03 AM, Toby Murray (in response to above) wrote:
...
 > Plash already implements a powerbox. As well as using a modified glibc
 > (to turn open() etc. into capability invocations), it also includes a
 > library that can be LD_PRELOADed to intercept calls to the GTK File
 > Chooser to turn these into capability invocations on a powerbox.
 >
 > This allows regular programs like editors and such to work as expected
 > and be oblivious to their capability-based underpinnings.
 >
 > Essentially, Plash presents a POSIX interface implemented on top of a
 > capability system. (The fact that the entire cap system is implemented
 > in userspace on top of a real POSIX system isn't really relevant here.)

but of course as with my chmod example, PLASH would seem to provide
no interface to the underlying capability infrastructure, specifically
for delegation (sharing) of authority.  That is where I was suggesting
that something like "caplib" could be needed - if we had enough
of an underlying capability infrastructure to make it worthwhile.
At least capability manipulation could have an agreed upon API.

>>> There is a large and
>>> growing body of embedded systems that are slowly morphing into
>>> application platforms.
>> I'm interested to hear more about application level support in
>> such systems.
> 
> There isn't any to speak of. What is going on at present seems to be
> that each of these devices has it's own application infrastructure that
> is largely incompatible with all others. Customers aren't yet noticing
> that bottleneck, because there is another bottleneck ahead of it: the
> device vendors are impeding the transfer of user data.
> 
> Consider, for example, that on most cell phones you cannot
> straightforwardly migrate your address book to a cell phone from a
> different vendor (or even, in some cases, the same vendor).
> 
> Since the data is effectively captive, questions of application
> compatibility become moot.

Hmmm.  What about the issue of "third party" software?  It has
generally been when significant amounts of software started being
developed for a platform (e.g. the PC, Mac, Unix) that the issue
of the API becomes significant.  Are the software developers
all working still to support a single vendor at this point?

>> Are you suggesting that this body of embedded systems that are
>> 'slowly' morphing into application platforms now have sufficient
>> mass that if I was facing the dilemma that Bechtotsheim, Baskett,
>> and Pratt faced of needing a body of application support software
>> to deliver end user value to a platform, that I could use this
>> set of applications written to run over embedded systems to sell
>> an end user platform?  Would that mean abandoning the existing
>> open source (mostly GNU?) software?
> 
> No. I am saying that the platforms on which open source applications now
> run are slowly but inevitably becoming less and less significant, and
> that the applications which run on embedded platforms have only limited
> overlap with desktop applications. This does not entail abandoning
> existing open source software (which, aside, is definitely NOT "mostly
> GNU"), but it does suggest that a new application platform based on a
> different foundation is not out of the question.
> 
>>> As to desktop applications, there has been a significant shift. 10 years
>>> ago, there simply *weren't* any open source desktop applications worth
>>> mentioning.
>> Hmmm.  Of course much (most?) of the GNU suite of software was
>> available 10 years ago.
> 
> Yes. But outside of a few developers, nobody gives a damn (or should).
> The applications that actually deliver value to the world at large are
> things like Evolution (email), Firefox (browsing), and OpenOffice. It is
> also noteworthy that NONE of these are GNU applications.

While the above may not be GNU applications, I agree with Toby that:

On 2/29/2008 10:03 AM, Toby Murray (in response to above) wrote:
 > These applications all depend on the standard POSIX interfaces.

However, when Toby further comments:

 > Plash indicates that such interfaces can be reimplemented on top of a
 > capability system and, furthermore, when one does so, one ends up with a
 > POSIX environment that more naturally lends itself to POLA.

I believe what PLASH shows is that much of the semantics of the POSIX
environment can be supported without an API change on top of a
capability environment - essentially in compatibility libraries.

However, even if we were able to support the full POSIX interface
(unlikely at least with mechanisms like chmod, perhaps
pipes, likely others), we'd end up with a bloated POSIX
platform.  What would the underlying capability platform
contribute to applications?  Just tighter "security" (more
POLA)?  Is that enough?

I personally believe that until we get capabilities visible
outside the API, not just at the application level, but even
up at the level where people are aware of them (e.g. as units
of sharing/delegation), we won't have a significant impact
on the IT world.

If others don't believe that something like a "caplib" is
needed (I can certainly understand that argument), then how
do they foresee capabilities providing value to applications
and more importantly to people?

--Jed  http://www.webstart.com/jed/