managing capabilities without encryption

12.7: adda/cstr/managing capabilities without encryption:
. in a read of capability-based security
I wondered if there was some way to
have capability enforcement
without having to encrypt all the shared pointers .
. related ideas include:
# Singularity's faster task switching
done by using ref's to shared mem'
instead of passing copies between modules;
# how to use pointers to shared resources
so that even though 2 concurrent sharers
were both active at different processors,
only one active sharer at a time
would have a useful link to the shared resource .
sketch of a possible design:
. a process can never reach out directly,
but is always accessing things via
pointers located in their header,
and only the supervisor can modify this header;
eg, the task scheduler .
. it's not enough to have possession of a pointer,
you've got to have a supervisor
copy it to your header;
so, it's like encryption,
in that it requires an authorization .
layers for when bugs happen:
. encrypted cap'pointers are being
another level of security; [12.25:
. cap'based is supposed to include
the soa idea:
. bugs are going to get into the system,
but in a software system that
connected it's modules
the same way https connects computers,
then it wouldn't matter bugs had invaded;
because each of the components is
being separately guarded by modularity
(not allowing direct access to state)
and is working only with ID'd clients
(not servicing anonymous agents).
. the idea of unencrypted header pointers
is assuming that
the system's runtime can be secured
which is not likely
on today's monolithic OS's .]

minix vs Amoeba

news.addm/cap'based/minix vs Amoeba:

6.21:

. amoeba is cap'based?

amoeba was started by the creator of minix

(minix features high security via a microkernel);

but, amoeba is languishing while minix thrives ?

rationale:

. amoeba is a research project for a distributed os

(for doing supercomputing with networked computers)

while MINIX 3 is more important to the masses:

. well suited for Single-chip, small-RAM, low-power,

$100 laptops for Third-World children

and Embedded systems (e.g., cameras, DVD recorders, cell phones)

--. the lang that amoeba now supports is Orca,

7.7:

. why is cap'based security not an advertized feature of minix?

. the author of minix, Tanenbaum, wrote in 1990

that the use of cap'based security

was one of the things that amoeba did right .

. however, if small mem'size is key,

then it becomes significant that cap'based security

can be implemented as an optional add-on

using a cap'based programming language .

. another priority that minix excels at is being unix:

"(

amoeba's UNIX emulation will never provide 100% compatibility.

For example, the whole concept of user-ids and group-ids

is very hard to get right in a capability-based system.

Our view of protection is totally different.

Furthermore, Amoeba is essentially a stateless system.

This means that various subtle properties of UNIX

relating to how files are shared between parent and child

are virtually impossible to get right.

In practice we can live with this,

but for someone who demanded binary compatibility,

our approach has some shortcomings.

)

. nevertheless, the cap'based OS has advantages,

according to the authors of keyKOS,

"(

. There are no other mechanisms adding complexity

to the ideas or to the implementation .

It is worthwhile to contrast this approach

with the ring-structured security model of the Intel 80x86 family .

. The capability model is intrinsically more secure.

A ring-structured security policy is not powerful enough

to allow a subsystem to depend on the services of

a subsystem with lesser access rights.

Ring policies intrinsically violate the principle of least privilege.

In addition, ring-based security mechanisms convey

categorical authority:

any code running in a given layer

has access to all of the data in that layer.

Capability systems allow authority to be minimized to just that

required to do the job at hand.

Using a capability model offers significant simplifications in the nanokernel.

Among the questions that the nanokernel does not have to answer are:

* Does this user have the authority to perform this operation?

(Yes - if you hold the key you can send the message.)

) .