[cap-talk] "opaque" confinable capabilities as data (was: POLAcanthus)

[Jed Donnelley]

On 11/16/2007 10:33 AM, Mark Miller wrote:
> On Nov 16, 2007 10:14 AM, Mark Miller <erights at gmail.com> wrote:
>> http://www.mail-archive.com/linux-security-module@vger.kernel.org/msg02028.html
> 
> Following some links from there took me to http://polacanthus.net/
> 
> Good stuff Rob!

I agree - good stuff.  Makes me think that somebody could
provide a very useful service by putting together a
modern bibliography/taxonomy on the capability literature.
To me it seems that the literature in this area is
getting rich enough that being able to keep up with
the diversity and fit it together is becoming difficult.

The above led me to the Practical Unix Capability
System paper:

http://www.imperialviolet.org/binary/pucs.pdf

which I couldn't have more than glanced at before.

I enjoyed the brief section of what might be referred
to as capability "fundamentals" including Adam
Landley's definition:

"A capability is an opaque channel which names an object
and authorizes its holder, an agent, to use it."

and his discussion of some examples of non capabilities
such as Posix 'capabilities' (clear) and password
'capabilities' (e.g. such as in Amoeba, NLTSS,
Monash, and others).

He then summarized the different properties of
"security objects" as:

Names		| Y | N | Y | N | Y | N | Y
Authorizes	| N | Y | Y | N | N | Y | Y
Opaque		| N | N | N | Y | Y | Y | Y
		___________________________
		|   |   |   |   |   |   |
		| F | P | P | ? | ? | U | C
		| i | a | a |   |   | I | a
		| l | s | s |   |   | D | p
		| e | s | s |   |   |   | a
		| n | w | w |   |   |   | b
		| a | o | o |   |   |   | i
		| m | r | r |   |   |   | l
		| e | d | d |   |   |   | i
		|   |   |   |   |   |   | t
		|   |   | c |   |   |   | y
		|   |   | a |   |   |   |
		|   |   | p |   |   |   |
		|   |   | a |   |   |   |
		|   |   | b |   |   |   |
		|   |   | i |   |   |   |
		|   |   | l |   |   |   |
		|   |   | i |   |   |   |
		|   |   | t |   |   |   |
		|   |   | y |   |   |   |

I don't agree with the "opaque" characterization.

I believe the essential difference between what
are referred to as "password capabilities" and
object/capabilities is the confinement property.

I believe that one can construct a capability
as data mechanism that has all the essential
properties of object/capabilities. I think this
fact is important for my "CapBrowser" project
where I hope to bring intuitive copy and paste
'capability' delegation/authorization to
the Web masses (the world).

Of course one doesn't need a capability as
data for such a facility.  In principle a
descriptor type capability mechanism
(e.g. think KeyKOS, EROS, or even E)
would suffice if one included a DCCS-like
translation mechanism.  However, I believe
there are vital practical advantages to
using capabilities as data (but still
object/capabilities) for this purpose.

I have yet to do battle to convince
(or be convinced) others that such
object/capabilities as data are indeed
possible, let alone useful.  However,
I hope to soon (e.g. along the lines
I described previously on this list).

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