Re: Access Control

Alice could create a program to make the changes, but a cron job is what
most people would use to avoid writing code.  I think I'll leave it barring
strong objections.

A rogue sysadmin can do so much damage, not changing Bob's permissions
should be the least of your worries.

--------------
Alan Karp


On Mon, Aug 25, 2025 at 10:26 AM Bob Wyman <bob@wyman.us> wrote:

> Yes, I largely agree. However, I had previously considered the option of a
> cron job but then was uncomfortable that this would mean that the security
> of the system depends on the security and reliability of the cron daemon.
> (Could a rogue system administrator temporarily disable cron in order to
> preserve existing privileges long enough to allow a co-conspirator to do
> something bad?) Relying on cron seems a bit fragile to me, but I do accept
> that it is a potential, although perhaps risky, solution to Alice's problem.
>
> bob wyman
>
>
> On Mon, Aug 25, 2025 at 1:03 PM Alan Karp <alanhkarp@gmail.com> wrote:
>
>> I updated the delegation section to include the hazard of expensive
>> mechanisms.  Does the following capture your thinking?
>>
>> Yet another hazard is the need to enforce complex policies.  Mechanisms
>> that are too inconvenient or that cost too much in time or resources are
>> unlikely to be used.  Say that Alice wants a delegation to be valid only
>> during business hours.  That policy is unlikely to be enforced if Alice
>> must manually issue or revoke the delegation at each change.  Automation
>> is commonly used to mitigate this problem.  For example, Alice can set
>> up a cron job to make the changes to the ACL.
>>
>> --------------
>> Alan Karp
>>
>>
>> On Sat, Aug 23, 2025 at 8:34 AM Bob Wyman <bob@wyman.us> wrote:
>>
>>> Alan,
>>> You wrote: "I should have focused on the hazards rather than the
>>> mechanisms."
>>> I think that when considering the hazards inherent in various
>>> mechanisms, we need to evaluate not only technical risks, but also economic
>>> risks. And, we should be aware that whatever may be the virtues of
>>> alternative mechanisms, if the economic cost of their use is high enough,
>>> the real "hazard" is that no mechanism will be used.
>>>
>>> When evaluating technical risks due to a mechanism's design, we normally
>>> make the dangerous assumption that implementations of the mechanism's
>>> components and dependencies will operate as designed. Some risks will be
>>> inherent to the design of the mechanism itself. (e.g. Composition has
>>> issues that we've touched on.) However, an important class of risks are due
>>> to the inevitable fragility of systems' implementations. We are all too
>>> well aware that essentially all systems can be hacked or circumvented.
>>> (e.g. Any system that relies on the difficulty of breaking some crypto
>>> algorithm is exposed to the risk that someone will make the economic
>>> decision that it is worthwhile to spend sufficient resources to overcome
>>> the difficulty.)
>>>
>>> Economic risks often dominate the risk horizon. Cumbersome systems, even
>>> if technically well designed, are often not used. It is probably Alice's
>>> desire to avoid the cost of having Bob forward long lists of proposed
>>> actions to her that motivates her to empower Bob, via delegation, to act on
>>> his own. But, while avoiding the cost of serving as Bob's proxy, Alice
>>> accepts the offsetting risk that Bob will do things that she's unaware of
>>> or of which she would not approve. Nonetheless, she may accept the costs
>>> associated with delegation if they appear to be "acceptable." Delegation
>>> might not be perfect, but for Alice it may be good enough and "cheaper"
>>> than any alternative. Others might evaluate the tradeoffs differently.
>>>
>>> The really big problem arises when the economic cost of the available
>>> mechanisms is so high that no mechanism will be employed. For instance,
>>> while Alice may wish that her 1,024 international employees only have some
>>> capability during their assigned working hours, the economic cost of Alice
>>> making thousands of delegations and revocations each day is likely to be so
>>> high that, unless an automated mechanism is available, Alice simply won't
>>> even attempt to implement her desired policy. In this case, the hazard and
>>> risk is that no mechanism will be used to address the problem. Of course,
>>> Alice might regret her tradeoff analysis on the day after some employee
>>> goes rogue after-hours...
>>>
>>> So, I think the hazards (costs) evaluated should include both technical
>>> and economic costs and risks. We must be aware of the risk that even
>>> well-designed mechanisms will either not be used or will be circumvented if
>>> they are cumbersome (i.e. have high economic cost).
>>>
>>> bob wyman
>>>
>>>
>>>
>>> On Fri, Aug 22, 2025 at 6:50 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>>
>>>> You're right.  I used the wrong criterion.  I should have focused on
>>>> the hazards rather than the mechanisms.  The question I should have asked
>>>> is if the example introduces a new hazard.  Relying on existing mechanisms
>>>> was a poor way of deciding.
>>>>
>>>> Most, if not all, of your examples can be handled by the verifier, the
>>>> PDP for those of you in the know.  Nothing says the verifier can only look
>>>> at the authentication for ACLs or the certificates for capabilities.  It's
>>>> free to include whatever additional information it needs, such as whether
>>>> the US is at war with Canada.  (That used to be funny.)
>>>>
>>>> While the verifier is part of the access control system, Cedar shows it
>>>> is possible to enforce complex policies without specialized code.  That
>>>> means examples such as blocking certain compositions don't represent new
>>>> hazards; they just need to be included in the policy.  On the other hand,
>>>> the verifier can't deal with the confused deputy example.  It sees a
>>>> legitimate request from Bob but has no way to know Bob made that request
>>>> because Alice asked.  That makes it a hazard.
>>>>
>>>> As your list demonstrates, there's an unbounded set of policies.  We
>>>> certainly don't want to include a specific mechanism in our design for each
>>>> one of them.  Instead, we want our access control system to deal with cases
>>>> that the verifier may not see, such as delegations, or that can't be
>>>> expressed as policies, as with the confused deputy.  Which of your examples
>>>> do that?
>>>>
>>>> Thanks for the insightful comments, Bob.  They've helped me clarify my
>>>> thinking.
>>>>
>>>> --------------
>>>> Alan Karp
>>>>
>>>>
>>>> On Fri, Aug 22, 2025 at 1:59 PM Bob Wyman <bob@wyman.us> wrote:
>>>>
>>>>> Alan,
>>>>> You wrote: "The question is whether the policy introduces a new hazard
>>>>> or *if it can be enforced with an existing mechanism*"
>>>>>
>>>>> I think this constraint (i.e. "enforced with an existing mechanism")
>>>>> needs a bit more elaboration. Isn't delegation largely a convenience which
>>>>> could be enforced with an existing mechanism?  It seems to me that the
>>>>> effect of delegation could be provided by having delegatees simply send
>>>>> messages to the object owner, asking the owner to perform the desired
>>>>> actions. (e.g. Instead of Alice delegating to Bob, she could tell Bob to
>>>>> send her a list of commands that Alice would then issue herself and
>>>>> then forward the results to Bob. This "existing mechanism" would be
>>>>> effective, but would be terribly cumbersome.)
>>>>>
>>>>
>>>>> Similarly, as you suggest, Alice could delegate each day to Bob at the
>>>>> start of Bob's work day and then revoke that delegation at the end of Bob's
>>>>> work day. However, that would require Alice to get to work each day before
>>>>> Bob does and to stay at work until after Bob's work day ends. Of course, if
>>>>> she were the manager of an international organization with hundreds of
>>>>> members, she might be doing dozens of delegations and revocations at every
>>>>> hour of the day, every day. While cumbersome, this is an "existing
>>>>> mechanism" that is technically feasible, although not very practical.
>>>>>
>>>>> Rather than using your somewhat ambiguous definition of policy, I
>>>>> think it might be useful to distinguish between two classes of states or
>>>>> conditions:
>>>>>
>>>>>    - Things that can be detected by a machine (i.e. time of day, use
>>>>>    of user account, existence of intruder threat, outside temperature,
>>>>>    employee database status, etc.)
>>>>>    - Things that can only be detected by people, or that rely on
>>>>>    judgements made by people. (i.e. personhood, trust,  assessed competence,
>>>>>    etc.)
>>>>>
>>>>> It seems to me that an ideal access control system would be able to
>>>>> handle an arbitrarily complex set of machine-detectable states and
>>>>> conditions while we have no choice but to insist that only humans do those
>>>>> things that only humans (or their AI proxies?) can do. Now, I'll admit that
>>>>> one might wish to distinguish between an "ideal" access control system and
>>>>> a "practical" or implementable system... But, it is often good to
>>>>> understand the ideal before deciding how much less than ideal is one's goal.
>>>>>
>>>>> bob wyman
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Aug 22, 2025 at 12:52 PM Alan Karp <alanhkarp@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Aug 21, 2025 at 6:00 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>>
>>>>>>> So, if policy determines "how those permissions get assigned," but
>>>>>>> not the permissions themselves, then I assume that the following use cases
>>>>>>> would not involve policy:
>>>>>>>
>>>>>>
>>>>>> The question is whether the policy introduces a new hazard or if it
>>>>>> can be enforced with an existing mechanism.  I'm not saying that what I
>>>>>> suggest below is the best or even a good way, just that the mechanism can
>>>>>> enforce the policy.   The "verifier" I talk about below is the component
>>>>>> that makes the access decision based on Bob's permissions and his request.
>>>>>>
>>>>>>>
>>>>>>> After following some written policy guidelines, Alice delegates to
>>>>>>> Bob, but the delegated permissions she provides are constrained to work:
>>>>>>>
>>>>>>>    - Only for the two-weeks that she's out on vacation.
>>>>>>>
>>>>>>> Alice delegates to Bob before she leaves and revokes when she
>>>>>> returns.
>>>>>>
>>>>>>>
>>>>>>>    - Only between the hours of 6pm and 9am during weekdays which
>>>>>>>    are workdays.
>>>>>>>
>>>>>>> Alice delegates to Bob at 6 PM and revokes at 9 AM on every work
>>>>>> weekday.
>>>>>>
>>>>>>>
>>>>>>>    - Only if Bob has received a complimentary delegation from Dave.
>>>>>>>    (i.e. composition required)
>>>>>>>
>>>>>>> Alice asks Dave what he delegated to Bob before she delegates to
>>>>>> Bob.
>>>>>>
>>>>>>>
>>>>>>>    - Only if Bob can't compose Alice's delegation with any other
>>>>>>>    delegation. (i.e Bob can't do anything Alice couldn't do.)
>>>>>>>
>>>>>>> The verifier can enforce this policy.  (This approach is used in
>>>>>> consulting firms to implement a Chinese Wall between employees doing work
>>>>>> for competing clients.)
>>>>>>
>>>>>>>
>>>>>>>    - Only a maximum of three times
>>>>>>>
>>>>>>> Alice tells the verifier to tell her each time Bob uses the
>>>>>> permission and revokes after the 3rd use.
>>>>>>
>>>>>>>
>>>>>>>    - Only a maximum of three times during any 24-hour period
>>>>>>>
>>>>>>> Ditto
>>>>>>
>>>>>>>
>>>>>>>    - Only while the intrusion detection system is reporting a
>>>>>>>    suspected intruder.
>>>>>>>
>>>>>>> The verifier can enforce this rule.  (This approach is used in Risk
>>>>>> Adaptive Access Control.)
>>>>>>
>>>>>>>
>>>>>>>    - Only when the outside temperature is above 99 degrees.
>>>>>>>
>>>>>>> Ditto
>>>>>>
>>>>>>>
>>>>>>>    - Only if Bob's continued employment by Alice's employer can be
>>>>>>>    confirmed.
>>>>>>>
>>>>>>> Bob gets permission to invoke Bob-agent, and any delegations are to
>>>>>> Bob-agent.  You revoke Bob's permission to invoke Bob-agent when he leaves
>>>>>> the company.
>>>>>>
>>>>>>>
>>>>>>>    - Only if Bob uses the permissions to manipulate one or more of
>>>>>>>    an enumerated list of objects.
>>>>>>>
>>>>>>> The delegation only gives Bob permission to the enumerated list of
>>>>>> objects.
>>>>>>
>>>>>>>
>>>>>>>    - etc.
>>>>>>>
>>>>>>> I agree that policies like these are important considerations, but
>>>>>> do they introduce hazards that I didn't cover?  If so, then I should add
>>>>>> use cases for them.
>>>>>>
>>>>>> --------------
>>>>>> Alan Karp
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 21, 2025 at 6:00 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>>
>>>>>>> So, if policy determines "how those permissions get assigned," but
>>>>>>> not the permissions themselves, then I assume that the following use cases
>>>>>>> would not involve policy:
>>>>>>>
>>>>>>> After following some written policy guidelines, Alice delegates to
>>>>>>> Bob, but the delegated permissions she provides are constrained to work:
>>>>>>>
>>>>>>>    - Only for the two-weeks that she's out on vacation.
>>>>>>>    - Only between the hours of 6pm and 9am during weekdays which
>>>>>>>    are workdays.
>>>>>>>    - Only if Bob has received a complimentary delegation from Dave.
>>>>>>>    (i.e. composition required)
>>>>>>>    - Only if Bob can't compose Alice's delegation with any other
>>>>>>>    delegation. (i.e Bob can't do anything Alice couldn't do.)
>>>>>>>    - Only a maximum of three times
>>>>>>>    - Only a maximum of three times during any 24-hour period
>>>>>>>    - Only while the intrusion detection system is reporting a
>>>>>>>    suspected intruder.
>>>>>>>    - Only when the outside temperature is above 99 degrees.
>>>>>>>    - Only if Bob's continued employment by Alice's employer can be
>>>>>>>    confirmed.
>>>>>>>    - Only if Bob uses the permissions to manipulate one or more of
>>>>>>>    an enumerated list of objects.
>>>>>>>    - etc.
>>>>>>>
>>>>>>>
>>>>>>> bob wyman
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 21, 2025 at 8:34 PM Alan Karp <alanhkarp@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Thu, Aug 21, 2025 at 3:12 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>>
>>>>>>>>> Alan Karp wrote:
>>>>>>>>>
>>>>>>>>>> "Policy is a topic I chose to avoid."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How is "policy" distinguished from access control?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Policy decides who gets which permissions when.  Access control is
>>>>>>>> how those permissions are represented and used.
>>>>>>>>
>>>>>>>> For example, an ACL is an access control mechanism that represents
>>>>>>>> permissions but it says nothing about how those permissions get assigned.
>>>>>>>>
>>>>>>>> --------------
>>>>>>>> Alan Karp
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Aug 21, 2025 at 3:12 PM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>>
>>>>>>>>> Alan Karp wrote:
>>>>>>>>>
>>>>>>>>>> "Policy is a topic I chose to avoid."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How is "policy" distinguished from access control?
>>>>>>>>>
>>>>>>>>> bob wyman
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Aug 21, 2025 at 5:43 PM Alan Karp <alanhkarp@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, Aug 21, 2025 at 11:41 AM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>>>>
>>>>>>>>>>> When addressing Composed Delegations, you say:
>>>>>>>>>>>
>>>>>>>>>>>> Composable: Dave needs to be able to get one permission from
>>>>>>>>>>>> Alice, another from Bob and use them both in the same API call.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Imagine that Bob and Alice both have Q,U, and D privileges in
>>>>>>>>>>> respect to object X. Alice delegates Q and U to Dave. Bob Delegates U and D
>>>>>>>>>>> to Dave. Neither Bob nor Dave
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think you mean Alice
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> are aware that the other had delegated privileges to Dave. Now,
>>>>>>>>>>> Dave needs to do something to X that requires both U and D. Are you really
>>>>>>>>>>> comfortable with letting him combine the Q from Alice with the D from Bob?
>>>>>>>>>>> Doing this would allow Dave to do something that neither Bob nor Alice
>>>>>>>>>>> intended him to do. In fact, both Bob and Alice might be very surprised to
>>>>>>>>>>> learn that Dave had, in fact, done that thing.
>>>>>>>>>>>
>>>>>>>>>>> You could also ask if Alice's delegation to Dave violates some
>>>>>>>>>> policy.  Policy is a topic I chose to avoid.
>>>>>>>>>>
>>>>>>>>>> If you want policy enforcement, you'll have to mediate
>>>>>>>>>> delegations in some way.  However, you still need to deal with credential
>>>>>>>>>> sharing to get around blocked delegations.
>>>>>>>>>>
>>>>>>>>>> --------------
>>>>>>>>>> Alan Karp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Aug 21, 2025 at 11:41 AM Bob Wyman <bob@wyman.us> wrote:
>>>>>>>>>>
>>>>>>>>>>> When addressing Composed Delegations, you say:
>>>>>>>>>>>
>>>>>>>>>>>> Composable: Dave needs to be able to get one permission from
>>>>>>>>>>>> Alice, another from Bob and use them both in the same API call.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Imagine that Bob and Alice both have Q,U, and D privileges in
>>>>>>>>>>> respect to object X. Alice delegates Q and U to Dave. Bob Delegates U and D
>>>>>>>>>>> to Dave. Neither Bob nor Dave are aware that the other had delegated
>>>>>>>>>>> privileges to Dave. Now, Dave needs to do something to X that requires both
>>>>>>>>>>> U and D. Are you really comfortable with letting him combine the Q from
>>>>>>>>>>> Alice with the D from Bob? Doing this would allow Dave to do something that
>>>>>>>>>>> neither Bob nor Alice intended him to do. In fact, both Bob and Alice might
>>>>>>>>>>> be very surprised to learn that Dave had, in fact, done that thing.
>>>>>>>>>>>
>>>>>>>>>>> bob wyman
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Aug 21, 2025 at 1:49 PM Alan Karp <alanhkarp@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I have followed a variety of access control systems off and on
>>>>>>>>>>>> for some 30 years, including the recent discussion on this list of the use
>>>>>>>>>>>> of OAuth 2.0 and 2.1.  I have concluded that many, if not all of them,
>>>>>>>>>>>> suffer from being based on use cases that are too simple.
>>>>>>>>>>>>
>>>>>>>>>>>> In an attempt to address that problem, I've constructed a bunch
>>>>>>>>>>>> of use cases <https://alanhkarp.com/UseCases.pdf> that I think
>>>>>>>>>>>> capture all the hazards an access control system must address.  Comments,
>>>>>>>>>>>> criticisms, and corrections will be appreciated and resented in equal
>>>>>>>>>>>> measure.
>>>>>>>>>>>>
>>>>>>>>>>>> --------------
>>>>>>>>>>>> Alan Karp
>>>>>>>>>>>>
>>>>>>>>>>>