[cap-talk] Selling capabilities programming

[James A. Donald]

Sandro Magi wrote:
> This is known as abstraction, which encapsulates sophisticated
> lower-level functions behind a higher-level interface. Are you
> suggesting that we discuss which abstractions are appropriate for end users?

Secure systems typically come under attack at the weakest link - the 
user (who is usually also the system administrator). If it was not for 
those dang end users, it would be easy to make a 100% secure system.  :-)

Thus an elegant explanation of why my great idea is 100% secure, and 
other great ideas are not, needs to viewed with extreme suspicion when 
an account of end users is entirely absent from both ideas.

> So it's not that this work isn't being done, or considered, but to a
> certain extent we're just not quite there yet.

The user is where you need to start.  In order to "protect" must protect 
against threats, to protect against threats, must have a threat model. 
Who is being threatened?  The end user.

> Let's be more concrete: what do you envision as this 80% solution
> capabilities could provide that wouldn't leave exploitable
> vulnerabilities? "Capabilities all the way down or bust" seems
> fundamental to the safety of the model, but I'd like to hear
> alternatives. Are you referring to something like BitFrost or Plash?

Bitfrost is very much what I have in mind, though Bitfrost is written 
very specifically for a very cheap laptop.

Also what I have in mind is Plash plus bunch of other stuff:  Plash plus 
a cap shell in place of bash shell, plus something very like Synaptic 
Package manager, but which would install programs inside appropriate 
Plash sandboxes.

>> rather than proposing a perfect, complete, and
>> total solution to the problem, and every closely related
>> problem, without bothering to check, or even think
>> about, what users do in practice and need in practice -
>> without bothering to envisage key details of how the
>> proposed perfect and complete solution could in fact be
>> presented to end users and used by end users 

> Does Joe-E meet these criteria?

You don't present a language to end users.  You present a language to 
developers, who may develop, or fail to develop, a system that will be 
presented to end users and used by end users.  The trouble with any 
capabilities language is that we are *not* going to rewrite the world's 
software into that language, thus capabilities languages cannot address 
the present crisis.

Writing multithreaded, multiprocessor software is a hard problem, and we 
need a language to make it considerably easier.  Writing secure software 
is an easy problem.  What is a hard problem is dealing with millions of 
lines of software written by thousands of other people, mostly in C.  If 
you ask all those thousands of people to rewrite stuff in Joe-E, you 
will not get far.