Subject: Re: [e-lang] Modelling Blindness (was: "Capability =?iso-8859-1?q?Myths Demolished?=" (was: Software security workshop))

From: Tyler Close <tyler@waterken.com> · Date: Thu, 12 Dec 2002 08:41:25 -0400

On Wednesday 11 December 2002 23:26, Jonathan S. Shapiro wrote:
> On Wed, 2002-12-11 at 15:55, Tyler Close wrote:
> > Wow, this is really bad jargon. The interpretation of the sentence
> > in plain English is completely misleading. The Lampson model is
> > susceptible to the Confused Deputy and does not support
> > confinement, but is "more powerful" than a real capability system.
> >
> > Can you suggest a textbook that defines this modeling jargon?
>
> I think it's just really *unfamiliar* jargon. When you see the
> definition it will make perfect sense. A model is "strictly more
> powerful" than the system it models if the legal states and transitions
> in the real system are a strict subset of the legal states and
> transitions in the model.

Thanks for the definition. I still think it is an unfortunate
choice of words.  Surely you must agree that the plain English
interpretation of this jargon is misleading.

> On Wed, 2002-12-11 at 15:55, Tyler Close wrote:
> > Can you suggest a textbook that defines this modeling jargon?

This would still be useful. shap 

> The basic Lampson access matrix based formalism *does* support
> confinement, though other parts of the paper were unfortunately stated
> in ways that you and Alan Karp have already enumerated.

The main Lampson model, presented in the "Protection" paper,
explicitly *does not* support confinement. See rules b and c. shap 

In the text, Lampson suggests a possible technique for preventing
"de jure" transfer of authority.  The technique adds an 'augment'
authority to the model. shap

Nowhere does Lampson address "de facto" transfer of authority.  The
use of a "copy flag" in the model suggests that Lampson had not
even considered the issue.  I see nothing in the paper to suggest
that the access matrix model claims to be able to prevent
communication between a conspiring domain and object. If you wish
to refute this, please quote from the paper. shap

> I caution, however, that you seem to still be insisting on conflating
> some things and that this is getting in your way.

One of the purposes of this email thread is to find any holes or
inadequacies in the argument I have presented.  I am not aware of
any that you have presented evidence for. Perhaps I have missed
them. Please be very explicit in pointing out mistakes. Quote me,
state your argument and back it up. shap

> There is no one universal verification model for a system.

I have not suggested anything like this. 

It is also strange that you are saying that this is a flaw with my
argument.  The main point of my argument is that Lampson
over-reached with his model. Read the abstract for "Protection":

"Abstract models are given which reflect the properties of most
existing mechanisms for enforcing protection or access control, 
together with some possible implementations. The properties of
existing systems are explicated in terms of the model and
implementations."

Lampson is the one aiming for a universal verification model. This
is our main issue with his paper.  Lampson tries to prove that
there are nothing but implementation issues separating the
capability model from the ACL model. The main point of my argument
has been to show that Lampson was wrong about the generality of
his model. shap

> Showing that the deputy isn't confused is basically a value/control flow
> analysis at the source code level.

I am not sure what you are saying here. 

I would think that showing that the deputy isn't confused would be
very simple.  If designation and authorization are inseparable,
then it is simply not possible for the deputy to be confused. Once
you have defined what it means to be "confused", it is simple to
show that a capability system does not allow "confusion". A
possible definition for "confusion" is:

"A deputy is said to be 'confused' if processing of a request
makes use of authority that the deputy did not intend to apply to 
the request." shap

In a capability system, it is only possible to form a request by
selecting the permissions that the request should use.  It is not
possible to form a request without exactly specifying the
permissions to be applied.  This eliminates the possibility of
confusion. shap

Confusion is only a consequence of the fact that an ACL model
manipulates permissions in aggregate rather than individually. shap 

(Note: this argument applies only to the protection primitives. It
is possible to build an ACL system using a capability system.  In
this case, the Confused Deputy problem again becomes a problem.
Avoid ACL designs.) frantz

> The SW and DimTake models were developed to analyze a *particular* set
> of information and authority flow properties. The properties we were
> trying to analyze did not include the confused deputy property. The fact
> that these models don't address the confused deputy issue is completely
> irrelevant to anything.

I agree, and this is why I am criticizing the Lampson model and
not the SW model. 

> I think much the same confusion is happening in the discussion here
> about the Lampson paper. The Lampson model was not attempting to address
> many of the issues that this group finds important.

The problem is that Lampson never restricts the applicability of
his model.  It seems that his paper purposely does not restrict the
applicability of the model. It seems that Lampson did not
understand that his model has limited applicability. I have given
evidence for this viewpoint.

Please, if you believe otherwise, quote from the paper. This is
the crucial issue that we are discussing.  It is crucial that there
be little doubt on this issue. You've made an unsubstantiated
assertion on this issue. I am making a point of challenging your
assertion.  Please prove it or retract it.

I find it very ironic that, in "Protection",  Lampson explicitly
talks about the exact scenario that Norm used to demonstrate the
Confused Deputy problem. See the second example b in the
Introduction section. This should make it abundantly clear that
Lampson thought he was addressing the issues that we find
important. shap

> It was nonetheless a
> reasonable attempt at a model for the problems that it was trying to
> solve.

Exactly which problems the paper was trying to solve is at issue. 

> It was flawed, and in consequence some of the people here have
> spent a considerable amount of energy crapping on Butler.

This is patently false and inflammatory. Some of us have been
critical of the "Protection" paper.  Our criticism has been focused
and substantiated. No one has been "crapping on Butler". I request
that you retract this statement. I find the statement to be
extremely irresponsible and damaging for the discussion.

> I have to say that this is exceptionally disrespectful.

There has been nothing disrespectful in the arguments presented. 
They have been carefully prepared and studied arguments of the
points made in the "Protection" paper. On the other hand, your
characterization of these arguments as merely "crapping on Butler"
is "exceptionally disrespectful". I don't know if you intended it
to be. I hope we can clarify this.

> This stuff is **bloody hard**.

Then there should be no shame when mistakes are pointed out. shap 

> In short, I think people here may be ignoring the degree to which
> science is a process in which partial progress and semi-flawed results
> are both proper and necessary.

I don't see any evidence of this in the email archives. I see some
explicit evidence to the contrary.   Note that you are the first to
personalize any of the arguments being discussed.

Your knowledge of software security is a valuable resource in this
discussion.  I hope we can quickly put to rest these
personalization issues.

Tyler 
_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang