On Tue, Oct 13, 2009 at 8:12 AM, Doug Schepers <schepers@w3.org> wrote:
[out of order]
> So, I encourage feedback on the public-webapps list, rather than this
> one... I'm just the messenger here.
Indeed. Hence I'm replying on public-webapps cc'ing cap-talk.
> David-Sarah Hopwood wrote (on 10/13/09 12:41 AM):
>>In the few cases where anything more specific
>> has been said about use cases, they appear to be just about creating
>> another hoop for attackers to jump through, rather than actually
>> preventing them from doing anything.
>>
>> It is *not* harmless to add complexity to an already complicated and
>> poorly understood access control policy and mechanism ("Same Origin") in
>> a way that does not actually address the deficiencies of that policy and
>> mechanism.
>
> That's true, if it doesn't solve a real use case, then the added
> complexity is not worth it. The bone of contention is whether it solves
> a real use case. I don't have a prejudice either way here... at some
> point, both the proponents and opponents seem to step into hand-wavey
> mode and real discussion falls down. Frankly, there are simply too many
> jargon terms, metaphors, references and allusions, and problem-set
> shorthands being tossed around to ensure that everyone is on the same page.
>
> Maybe I think more visually, which is why I'd like a diagram (or
> several) of the problem space. Nobody has followed up on my offer to
> help with that, so either it's a bad idea, or people don't have time to
> help, or it's a good idea that doesn't meet someone's agenda, or
> something. I think it would be a good thing to add to the spec, or at
> least to a primer, to help newbies (like me) understand the real risks.
> Is there some reason that a set of diagrams would not be a good idea?
Diagrams would be an excellent idea! The previous attempts I am aware
of at diagramming confused deputy vulnerabilities and related issues
are
* The diagrams at <http://www.erights.org/elib/capability/deputy.html>
and <http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf> may help explain the
nature of confused deputy but may not be what you're looking for.
YMMV.
* Most relevant are the many diagrams in section 8.1 of Fred's thesis
<http://www.evoluware.eu/fsp_thesis.pdf>.
* Figures 1 and 2 from Fred Spiessens' "The Oz-E Project: Design
Guidelines for a Secure Multiparadigm Programming Language"
<http://www.info.ucl.ac.be/%7Efsp/oze.pdf>. (Much of the rest of that
paper appears elsewhere in Fred's thesis, but not these diagrams.)
* Ihab's diagrams at
<http://www.eros-os.org/pipermail/cap-talk/2009-June/012872.html>
illustrating issues with Adam's example (see the enclosing thread).
* Table 2 of Tyler's "ACLs don't"
<http://waterken.sourceforge.net/aclsdont/current.pdf>. The issue
Tyler raises in that paper, of delaying the access check till after
the crucial information has been lost, may well be diagrammable in
terms of dynamics of such access matrices.
Once we have good ways of diagramming the general confused deputy
issue, we can try illustrating Tyler's CORS counter-example with these
diagrams.
I wish you great luck with this diagramming effort. Good diagrams for
helping illustrate this problem would be great. As you say elsewhere
in this thread, it is hard to explain this well in words, especially
when communicating between access control paradigms where the words
may have subtly different meaning.
Besides diagrams, the other cure for "hand-wavey ... jargon terms,
metaphors, references and allusions, and problem-set shorthands" is
formalism. See the formalization of the confused deputy in that same
section 8.1 of Fred's thesis. Fred's formalisms and diagrams help
explain each other. The system Fred built for mechanized reasoning
about access control, SCOLLAR, he has also used for modeling the
access control properties of stack introspection. Since, as Tyler
explains, CORS is closer to stack introspection than to single-level
ACLs, perhaps developing a formal model of CORS in SCOLLAR would be
helpful. I leave that question to the formalists -- a set of which I
am not a member ;).
Because email arguments have their own rhythm to them, and because the
many good responses to my previous messages all deserve careful
replies, I need to mention that I'm about to be traveling for two
weeks on a family issue, and may be too busy to give this thread the
attention it well deserves until I get back. I will try to find time
for some responses. But given the stakes I would rather post careful
responses after annoying delays (sorry) than to post sloppy responses
quickly. If things go well I will be back in time for TPAC.
--
Cheers,
--MarkM