[cap-talk] Reasoning about dynamic vs. static (was: POLA: what about dynamics?)

[Jed Donnelley]

cap-talk,

There is something in the discussion with Rob Meijer that's
been sticking in my craw for a couple of weeks that I've
been meaning to bring up.  The discussion about dynamics
regarding Doug Crockford's mashup summit proposal brought
it to the fore.

On Thu, September 20, 2007 14:31, Rob Meijer wrote:

> ... do you have any clue as how to
> translate such a rule of thumb to POLA systems with delegations instead of
> static priviledges? If the rule of thumb for POLP is wrong to begin with,
> is there any alternative way to choose the most POLP/POLA compliant
> decomposition in such a way that risk is minimized?

and Rob had earlier written:
On Thu, September 20, 2007 03:49, Rob Meijer wrote:

> My problem is now that having used the static variant in the preceding,
> I would like to use the same line of reasoning to show how a
> similar rule of thumb could be made for finding the most proper functional
> decomposition based on dynamic free delegation, revocation and
> authority, and if possible showing at the same time that applying the
> same rule of thumb to the static variant, that the dynamic variant should
> in many cases translate to a lower risk factor for a composite project.

The above seems to suggest that reasoning about security
is easier with "static" privileges and is made more
difficult when dynamic delegation of permissions is available.

I want to at least make clear my belief that it isn't
dynamic delegation of permissions that makes reasoning
about security more difficult but rather just the existence
of communication channels that makes such reasoning more
difficult.  This is in accord with the oft stated principle
on this list that when a communication channel is available
authority can be delegated even if there is no explicit
delegation mechanism available (e.g. no mechanism to
update ACLs such as the vat with the authority not having
access to a particular ACL).  That is, no "static"
mechanism for privileges can stop delegation across
existing communication channels.

I just wanted to check to see if Rob shares this view or
if further discussion of this point might be worthwhile.

We seem to see situations come up again and again
where some (in my view misbegotten) concern about
delegation without authorization adds what to me
is a redundant authorization step to a delegation
process.  The OAuth example is the most recent.

If I have access to a service (e.g. a picture storing
service) that gives me an effective 'object' view
(e.g. each picture is a distinct object) and such
a service gives me the ability to share access to
"my" objects effectively (e.g. including the ability
to delegate access to an individual object), then
I believe I should be able to do such delegation
with what amounts to a single step.  E.g. I should
be able to drag a link to one of my pictures into
a printer window to grant a needed access.  I might
also have to drag over some money, but I at least
hope that I don't have to be asked a second time
about authorizing such access that I have already
delegated - particularly if the only justification
is to simplify reasoning about the security of the
systems involved - since I argue that no such
simplification is actually provided.

Perhaps I'm missing some real added value to such
additional authorizations?  If so, perhaps somebody
could explain them to me.

--Jed