[cap-talk] Re: New paper: The Structure of Authority - notes and meat

[Jed Donnelley]

At 07:22 AM 11/12/2004, Mark Miller wrote:
>Mark Miller wrote:
>>At <http://www.erights.org/talks/no-sep/index.html>.
>
>Jed, all,
>
>Please have a look especially at section 3.2 of our paper. In that section 
>we attempt to clarify what security claims can be made when security is 
>built on an object-capability language, even when running on a 
>conventional non-cap OS. I hope we have also been clear about the limits 
>on what can be claimed when in this situation.
>
>Now that we've written down specific limited claims, there's something 
>concrete to argue about. ;)

As I commonly do with such papers I need to read the whole thing to get the 
context.
As I do I take notes from trivial to significant as they occur.  However, 
for those who
might wish to jump to the technical meat of the discussion about language 
enforcement
of protection domains, I suggest jumping to the section labeled 3.4a about 
3/4 toward
the bottom of this email.

Here are my notes by section number:

1a.  No page numbers?

1b.  "...receive the UI events..."  I suggest spelling out UI as user 
interface.
Great first paragraph incidentally.  Tells it just like it is.

1c.   I like the cp/cat example.  However, I don't understand this last 
sentence in
section 1: "Ironically, only their support for the first style is explained 
as providing a form of access
control."  Are you referring to the typical user/group/world sort of access 
control nominally
for humans but also what is available to programs?  That sentence was a bit 
ambiguous to me.

2a.  I'm a bit puzzled by the title of section 2: "Composing Complex 
Systems".  It seems
so general as to be nearly meaningless.  What about "Combining Designation and
Authority"?  I'll read on and see if something more appropriate comes to mind.

2.1a  "Objects can send messages along these references..."  Is this usual 
terminology
for calls or invocations on objects in OO programming languages?  "send 
messages"?
I admit I'm not up on such terminology, but I'm a bit surprised at that 
phrase in this
context.  If other terms (like the "call" or "invocation" or ...) are also 
used I think it
might be helpful to include some alternatives to make clear that you are being
inclusive here - as I assume you are.

2.1b - last paragraph.  Hmmm.  You say, "By claiming that security is not a 
separable
concern...".  In doing so it seems to me you've put yourself needlessly on the
defensive.  I don't even see such a claim.  What I see is a straightforward and
effective (up to that point) argument for combining designation with access 
control.

Still, the rest of the paragraph is good.  My simplest suggestion would be 
to do
something simple with the first sentence like:

By arguing for the combining of designation and authority <subtle plug for my
alternative section title and binding back to the title> we do not suggest that
no separation of these issues is possible.

2.1c  Also later in that last paragraph you say, "...separately from the 
practice of
designing and building systems."  I suggest, separately from the practice of
communicating references when systems are designed and build.  I believe it
is only the combining of designation and access that you are arguing for here,
not anything more general about designing and building systems.

2.2a  "Objects that do not know about one another, and consequently have
no way to interact with each other, cannot cause each other harm." is the first
place that I start to get concerned about your line of thought.  Consider for
example a JPEG file set up to exploit a flaw in JPEG viewing software in
such a way as to take control of the software and install a Trojan horse on
a system.  Perhaps such a JPEG file goes beyond your notion of "object"
in this context, but I would argue that such a JPEG file (or its construtor)
only knows about the 'objects' in the system that it is targeting from general
knowledge of the architecture of the system.  It certainly has no explicit
designations with or without rights granted.  Still, it is able to do a great
deal of harm by exploiting a fairly simple flaw.

I can accept a statement like this, 'By combining designation with authority,
the logic of the object-capability model explains how computational decisions
dynamically determine the structure of authority in our systems - the topology
of the "access-to" relationship.' in so far as it goes.  However, by seeming to
suggest that the logic of the model effectively constrains attempts to go 
outside
the logic of the model I think you go too far.  I read on...

2.2b  This sentence, "We can identify four majors layers of abstraction: at the
organizational level systems are composed of users; at the user level, systems
are composed of applications; at the application level, systems are composed of
modules; at the module level, systems are composed of objects." seems a bit
strained to me.  Since it seems to go to the heart of your discourse I thought
I would question it.  You are referring to computational systems.  You 
start with
"users".  In what sense are 'users' part of the computational system.  Are you
referring to the real people or to the representation of a 'user' (e.g. 
UID, etc.)
in a system?  I'm not sure how, but it might help to clarify that.

Accepting that you are referring to a system representation of a 'user', then
you complete your nesting as: user, application, module, and object.  To
me this nesting seems rather weak.  Users run programs in processes.
Is the program the "application" (as with usual terminology) or is the process
or something else?  I'm a bit lost in identifying what dimension this nesting
is following.  If you are following an access control nesting (which seems
reasonable given the thesis of your paper) then I can see a nesting of
users -> processes.  That is, users are in control and run processes.
Users (again as their system representations) are indeed separate
rights domains.  Processes are in some sense subservient to the
user domains and have some notion of their own domain - which can
of course be made more "pure" (separated from users) with the object
capability model where processes are independent entities interacting
by virtue of their owned capabilities.

We'll see where the module and object 'layers' lead later I assume.

2.2c  The Herbert Simon paragraph - somewhat motherhood and apple
pie.  Still, I can see the argument for the value in noting the 
compartmentalization
of communication.

2.2d  The end of the second to last paragraph:

Abstraction boundaries, by hiding implemen-
tation details, allow clients to ignore distractions and focus on their 
remaining
concern. Applied to authority, abstraction boundaries protect clients from fur-
ther unwanted details; by denying the provider authority that is not needed to
do its job, the client does not need to worry as much about the provider's 
intent.
Even if the intent is to cause harm, the scope of harm is limited.

seems awkward to me and starts to sound a bit repetitive.  The first part
of that paragraph seems reasonable to me, but when you say abstraction
boundaries applied to authority protect clients from unwanted details
it seems to me you are mixing things up.  The authority part has nothing
to do with unwanted details but has everything to do with protection from
harm.  Let me take a crack at the above:

Abstraction boundaries allow clients to focus on work at the level of
their task and ignore implementation details for services they call.
When applied to authority such abstraction boundaries can also
relieve clients of concerns about possible harm from providers.

3a.  Why is "(In this paper, we do not show such resizing, as the
knowledge needed to quantify these issues is largely inaccessible).
parenthetical?  The parenthesis don't seem to add communication
value to me.

3b.  When you say, "While it is well-recognized that the active entities in an
access matrix can be either people or processes, the precise relationship 
between
them is rarely recognized in any systematic way. We show how the same nesting
of levels of abstraction, used to organize system functionality, can be used to
organize the authority needed to provide that functionality."

is the functionality that you refer to at the end the ability to recognize
the relationship between people and processes?  The above is a bit
unclear to me.

3.1a  TCB discussion.  You say, 'Historically, "TCB" stands for "Trusted
Computing Base", but is actually about vulnerability rather than trust. To 
avoid
the confusion caused by the traditional terminology, we here define TCB as that
part of a system that everything in that system is necessarily vulnerable to.'

The above seems an unnecessary diversion to me.  Necessarily vulnerable to
or necessarily trusting seems a fine distinction.

3.1b  Here again the parenthesis seem out of place to me:

(Decentralized systems can escape this centralized vulnerability, and 
distributed
languages like E and Oz should support the patterns needed to do so. But this
issue is beyond the scope of this paper.)

Perhaps this is a style?

3.2a "...problems that, now, regularly infest our networks."  The commas
around "now" seem an unnecessary distraction (very picky I know...).

3.2b  I'll again rail against the use of parenthesis in:

"We will explain how Doug uses CapDesk and Polaris to reduce his expo-
sure while still running on a conventional OS. But first, it behooves us to 
be clear
about the limits of this approach. (In our story, we combine the 
functionality of
CapDesk and Polaris, though they are not yet actually integrated. Integrating
CapDesk's protection with that provided by an appropriate secure OS would
yield yet further reductions in exposure, but these are beyond the scope of 
this
paper.)"

The above seems to me a good place for a footnote:

We will explain how Doug uses CapDesk and Polaris to reduce his expo-
sure while still running on a conventional OS (#fn). But first, it behooves us
to be clear about the limits of this approach.
...
#fn In our story, we combine the functionality of CapDesk and Polaris, though
they are not yet actually integrated. Integrating CapDesk's protection with 
that
provided by an appropriate secure OS would yield yet further reductions in 
exposure,
but these are beyond the scope of this paper.

3.2c "(Drag-and-drop is supported by CapDesk, but not yet by Polaris.)"

Please, do I care?  Is it relevant?


...  Wait.  I just now finished section 3.2 that you (Mark) refer to in 
your message
as clarifying "what security claims can be made when security is built on an
object-capability language, even when running on a conventional non-cap OS."

The end of section 3.2 is still only referring to Doug's protection by only 
granting
more POLA access rights to applications he runs like Excel.  Perhaps you were
referring to section 3.3, "Module-granularity POLA within a caplet" and to 
section
3.4, "Object-granularity POLA"?  I read on...

3.3a  When you discuss how CapMail can be implemented with a "startup"
module that imports and presumably coordinates various other "modules"
that constitute the bulk of its code - I have no problem with the abstraction.
I ask - Do these separate modules that are given separate rights run in
separate memory spaces?  If so, then I have no difficulty in understanding
the implementation of the rights separation.  If they run in a common memory
space (more like subroutine 'modules') then I'd like to know how the
rights separation is enforced.

3.4a  OK, I read section 3.4.  I think this might be the point where I can
best probe what I think may be the essence of a disagreement about
"language" enforced separation of domains.  What I take that term to
really mean is enforced separation of domains within a shared memory
space that multiple 'modules' execute within.

The first point that I think is relevant is that "knows about" does
not equate to "can harm".  That is, even if I don't know about you,
if I have adequate rights (regardless of whether they are granted
through a known model or not) I can harm you.  In this section
3.4 you do refer to some language concepts like scope and
global variables.  These concepts are fine as long as you stay
within the model of the programming language(s).  However,
doing harm often comes about by breaking outside the
expected models.

What I need to understand about your thinking I believe
can best be cleared up by answering some questions like
the following:

If I am a program module running inside a constrained
domain inside a shared memory space with other such
constrained modules, what is to stop me from:

I.  reading or writing to any portion of the shared
memory space - whether to portions that I am
supposed to "know about" or not?  or

II.  executing any sort of "system call" (trap to
an external TCB) and acting on behalf of the
whole shared memory process with all its
rights?

While you may say that I (the malicious module)
don't know enough to carry out an effective attack,
I think I disagree.  By doing something simple like
stack walking I can likely find out a lot about the
environment I am running in and certainly get
access to information that within the language
model I am not to supposed to "know about"
(e.g. global variables).  Similarly by knowing
some simple conventions about the system I
may well be able to do harm by doing system
calls.  E.g. even in a classical capability system
I may know that by convention the capability at
index 0 or 1 or ... is to the user's "home" directory.
By fetching rights from that directory I can do any
amount of harm to the user.  Even if my process
is constrained, in principle I can examine the
rights that it possesses and try to do harm with
them.

When one is considering protections domains
enforced by an OS in separate memory spaces
with separate rights sets (e.g. c-lists) there is
no question of a rogue module in a process
adversely effecting the activities of another
process except through explicit communication
because the base TCB is able to protect each
from the other and constrain their communication
to that facilitated by explicit capability invocations -
e.g. as per Dennis and Van Horn.

However, within a single shared memory process
I don't see how such enforcement is possible.

Answer me that or point me in another direction
and perhaps we can proceed with this discussion.

When you say, "We thank Norm Hardy for first bringing
to our attention the intimate relationship between knowledge
and authority in computation." I think you may have
assumed that intimacy to go further than it actually does.

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