[cap-talk] Selling capabilities programming

[Mitsu Hadeishi]

> In order to control what matters, it is necessary to let
> go of control of what does not matter, or else users
> will be overwhelmed by detail, and will proceed to grant
> coarse grained permissions.  Every proposed constraint
> or goal, every behavior that supposedly must be
> monitored or controlled, therefore needs to be justified
> by a user interface case and examples of concrete
> threats, yet I see no discussions of user interface and
> concrete threats, no discussion of bad guys,
> adversaries, intrusion, fraud, deception, denial of
> service, theft of service, vandalism, violation of
> privacy, or wrongful intent.  The limiting factor is not
> how much control can be exercised by an all wise and
> omniscient administrator, but how to obtain the required
> amount of useful control from a very limited supply of
> user bandwidth, All requirements on capabilities systems
> need to be justified in terms of efficiency in
> translating user attention to limits on the misconduct
> of malicious software  and limits on the misconduct of
> buggy software processing hostile data.  I am not seeing
> any such justifications on this mailing list.

Hi, I've been lurking on this list for a while, but I felt like  
writing a few contributions here.  First of all, I agree completely  
with you, James, that concrete use cases (from a user standpoint)  
ought to be the central factor in deciding to what extent a specific  
set of features ought to be central to a system.  This is a lesson  
that is frequently overlooked.

>> The fundamental problem at Xanadu was all too
>> prosaic: it was about control and money.
>
> Technical overreach is obvious in the specifications -

I personally think a thrash about Xanadu is hardly likely to produce  
anything of benefit here, and I would encourage both sides to focus  
on capability security rather than rehashing debates about Xanadu.

> Capabilities programming, like Xanadu, focuses on the
> key problem of the era.  One should focus on the low
> hanging fruit, solving the eighty percent of the problem
> that requires twenty percent of the code, while having a
> plan to get to most of the higher hanging fruit in due
> course, 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 - with
> major aspects of the assumed total and complete solution
> being in fact far from total and alarmingly incomplete,
> the proposed solution being seemingly accomplishable
> merely because key areas of the problem have been
> ignored.

I believe the principles of capability security can be used in  
systems simply as a calculus of authority at a certain level of  
abstraction without having to insist that the entire language,  
operating system, and every interface be capability secure.  In fact,  
it is quite possible to use it as a drop-in replacement, to some  
extent, to a coarse-grained permissions system, and get a huge  
benefit, stemming from the logic of capability security, without  
insisting that every aspect of the entire system be completely  
capability secure.  That is to say, it is a useful programming  
paradigm and design approach for subsystems, in my view --- one still  
gains a lot of security advantages simply because, at least for users  
who are using the system at the level of abstraction at which one has  
defined the capabilities, there is a well-defined, fine-grained, and  
limited way to grant authority.  Of course, such a system wouldn't be  
the Holy Grail of a capability secure environment, because attacks  
that subverted the interfaces could break the security regime --- but  
it nevertheless has its use.

Thus, I would encourage people to think of capability security as an  
approach that can be used at many levels, and in many degrees ---  
it's still useful and can do a lot to improve security when used in  
this fashion.

Mitsu Hadeishi


> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk