Question about a capability pattern

[Alan Karp]

It is not unusual in an enterprise to have a chain of delegations that include people who may change jobs at any time.  For example, VP Alice delegates to department manager Bob who delegates to some worker bees.  You'll want to revoke Bob's capabilities if he leaves the company, but you'll also have to revoke all delegations that Bob made in case some were to a sock puppet.  However, that can disrupt operations of the department.

A proposed way around that is to delegate Bob's permissions to a proxy and give Bob a capability to the proxy.  When Bob leaves, revoke his access to the proxy.  Problem solved! Or is it?  While he's still the manager, Bob must be able to tell the proxy to delegate to members of the department.  What is to prevent some of those delegations being to a sock puppet?  Perhaps I misunderstood the proposal.

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

[Matt Rice]

On Mon, Dec 26, 2022 at 7:08 PM Alan Karp <alan...@gmail.com> wrote:
>
> It is not unusual in an enterprise to have a chain of delegations that include people who may change jobs at any time. For example, VP Alice delegates to department manager Bob who delegates to some worker bees. You'll want to revoke Bob's capabilities if he leaves the company, but you'll also have to revoke all delegations that Bob made in case some were to a sock puppet. However, that can disrupt operations of the department.
>
> A proposed way around that is to delegate Bob's permissions to a proxy and give Bob a capability to the proxy. When Bob leaves, revoke his access to the proxy. Problem solved! Or is it? While he's still the manager, Bob must be able to tell the proxy to delegate to members of the department. What is to prevent some of those delegations being to a sock puppet? Perhaps I misunderstood the proposal.
>

There is a somewhat different scenario where Alice/Bob are friends,
and members of a group, Alice has delegated some capability which can
be used by her friends & the group,
when Alice leaves the group, she wishes to revoke access to this
capability, to the group. Bob could have obtained the capability
through the group, and may need to switch some capabilities
from using capabilities available to the group with capabilities
available to Alice's friends. Usually Alice can give a capability to
her friends that translates a revoked group capability into a friend
equivalent one (for lack of a better term revocation withdrawl).
As for how this applies to your scenario, It seems really dependant
upon Past-bob's ability to manipulate the worker bee roster, if you
can't grant a new Post-Bob capability which did not exist in the Bob
era to a group you're certain excludes Bob you'd seem to have lost the
war.

At least, that is my not too deeply thought out initial impressions of
the situation...

[Raoul Duke]

one thing i wonder about is how the long term ui ux of all this works. i feel like it would at least potentially lead to users drowning in caps. and inevitably thered be more than one cap system if the way "sso" has been actually done in the real world at fang level companies is any indication. 

[Alan Karp]

On Mon, Dec 26, 2022 at 4:40 PM Raoul Duke <rao...@gmail.com> wrote:

one thing i wonder about is how the long term ui ux of all this works. i feel like it would at least potentially lead to users drowning in caps. and inevitably thered be more than one cap system if the way "sso" has been actually done in the real world at fang level companies is any indication. 

Having built several such prototypes, I can say that drowning in caps is not a problem.  The key idea comes from Marc Stiegler.  In order to operate on something, you have to designate it in the UI.  The trick is to use that act of designation as an act of authorization.  So, if you have a million capabilities for a million resources, you still need a way to say what you want to operate on.  Are you drowning in caps, or are you drowning in things you need to work with?  The latter is a problem orthogonal to access control.

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

[Raoul Duke]

I personally am a pessimist/realist so i expect that entropy of any
org will find wonderful old and new ways to eventually break the will,
break any chance of good ui ux e2e across the board. I expect things
like too many competing (more than 1 is too many) systems, uis, uxs,
of capabilities. Bad naming habits. Bad old half used / half unused /
but i am scared to clean them up in case i break something on the
other side of the world caps. Unclear chains. Terribly bad ui ux for
basic stuff that should just work and not be at all difficult to have
implemented well in the ui ux. Random bugs. Random security failures.
New vendor we have to migrate to for the Nth time. Incompatibilities
with anybody outside or even just contracting for the org. etc.:-)

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1aGQP%3Dpo3685mw1FPKsVgit7j8OSx2OS2T5G3dqwqkyg%40mail.gmail.com.

[Alan Karp]

I don't entirely disagree with your pessimism.  While we won't be able to fix the problems you list, we are able to demonstrate that solutions to them are possible.  Overcoming corporate inertia to get those solutions adopted is a big barrier.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAJ7XQb4Fs7MEw4Jz1FpgENwW%3DoiuDPgQ%3DvaMhrn5L7dr9H1PGw%40mail.gmail.com.

[Mark S. Miller]

How would shifting the problem from traditional corporations to hypothetical corporation-like DAOs change things?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2UEyfNdmiwH5Xbh%2B1pYkz5eUH%2BQWknzERCh6MB_6ASiA%40mail.gmail.com.

[Alan Karp]

On Tue, Dec 27, 2022 at 10:50 AM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

How would shifting the problem from traditional corporations to hypothetical corporation-like DAOs change things?

It would replace human failings with bugs :) 

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

[Rob Meijer]

Not sure if this can translate to a generic ocap pattern, but I've played around with membrane like patterns in the past where a 'subject' could get demoted (and possibly split-up) to (an) upstream 'namespace'.

So Alice delegates to Bob, Bob delegates to Carol. Bob stops being a subject, and at that point becomes the Bob namespace of the Alice subject. There could end up being another Bob namespace in for example the Andrew subject. 

At the moment Bob gets demoted from subject to namespace, Alice and Andrew become responsible for revoking anything in their respective 'Bob' namespace.

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z33OAeb-JB1b6NUgOrD4402UxYjzX3rmHFebWaQeyA19g%40mail.gmail.com.

[Alan Karp]

Nice.  Alice and Andrew can leave some delegations Bob made and revoke specific others, presumably including those he made to sock puppets.  The process may require human judgement, but that's OK.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAMpet1Uq7m6MtN8JHn-ZiRRiNQ%3D3VXu3DrH6qMmN1SL3bZ09jQ%40mail.gmail.com.

[Bakul Shah]

Wouldn’t a role based system handle this? The capabilities Bob has access to are a function of the role(s) he plays in the enterprise. If Bob leaves, others will typically have to take over his roles. So in a sense it is Bob who is the proxy for the roles he plays! Similarly anything he delegates in his role would be not to individuals but the roles they play. Now if a sockpuppet is given a legit role, that is a hiring issue! Typically assigning a role would be a different capability. This level of indirection can also allow others to fill in a role temporarily if Bob is not available or too busy.

Note that a role disappearing or morphing into other roles would be a much more deliberate decision and can be decoupled from people leaving.

On Dec 26, 2022, at 11:08 AM, Alan Karp <alan...@gmail.com> wrote:



[Alan Karp]

There are many legitimate reasons Bob may want to delegate to "himself."  For example, he may want to run a program with a subset of his permissions.  When Bob leaves the company, someone has to decide if that program is an important service to keep running or a back door for Bob to do mischief.  I don't see how roles help.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/A99C9B78-8705-41CD-B1F9-0B76AE7F0652%40iitbombay.org.

[John Kemp]

I agree that this is a nice pattern. An argument against it, I think, is that several (many?) individuals would need to make decisions about what to revoke once the subject became a namespace, and without centralized, automatic revocation of access, the revocation would not happen reliably. Is notification to Bob and Carol enough to ensure that revocation happens reliably?

- johnk

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3btVMrKANF%2BdDOfTL%2BdeEQgChR-yqzen1F9xcUOYp9yA%40mail.gmail.com.

[David Nicol]

I see an analogy to the legal concept of "capacity" when suing. For instance if I am going to follow through with suing a particular branch of the state of Missouri for rights violations, I will be naming as defendants the individuals involved in both their professional and personal capacities. The professional capacity is the role. The personal capacity is the individual. 

[Bakul Shah]

Well put! This makes it clear that Bob should not act in his personal capacity while doing professional work. This is what i was trying to get at.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAFwScO9KcJEfTvLGW%3DsgTzku_Qj7WV-3%3D8qCdnTVP6eW57mcWw%40mail.gmail.com.

[Alan Karp]

On Tue, Dec 27, 2022 at 4:36 PM Bakul Shah <ba...@iitbombay.org> wrote:

Well put! This makes it clear that Bob should not act in his personal capacity while doing professional work. This is what i was trying to get at.

The important word is "should."  It's not uncommon for employees, especially unhappy ones, to do things they should not.  In this case, Bob, thinking he's about to be fired, may delegate to a sock puppet to use as a back door. 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/D5274380-D12E-4914-8F52-EB6A1986908B%40iitbombay.org.

[Alan Karp]

On Tue, Dec 27, 2022 at 2:10 PM John Kemp <stable.p...@gmail.com> wrote:

I agree that this is a nice pattern. An argument against it, I think, is that several (many?) individuals would need to make decisions about what to revoke once the subject became a namespace, and without centralized, automatic revocation of access, the revocation would not happen reliably. Is notification to Bob and Carol enough to ensure that revocation happens reliably?

A delay in revoking the privileges of employees who leave a company is quite common.  I laughed at "Minority Report" because they didn't revoke access for the guy accused of murder.  Then I remembered the many cases of fired employees whose badges still worked months later.

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

[Pierre Thierry]

Scribit Alan Karp dies 26/12/2022 hora 11:08:

> What is to prevent some of those delegations being to a sock puppet?

And if we simply revoke all delegations made by Bob, it means every
"worker bee" in his former service now needs to reacquire
capabilities.

If they can do that easily, what would prevent the sock puppet to do
the same?.

So isn't the real question more about how to prevent Bob from creating
a sock puppet?

If there is a service that can authenticate genuine agents of the
system and extract their capabilities from Bob's membrane, you can
disable his membrane when he leaves the service/company.

So whenever Bob wants to delegate a capability, he just creates a
caretaker object that he gives access to a third party, like Zebra
Copy (or hist sock puppet). By default, the caretaker is inside Bob's
membrane. If Bob leaves the service, his membrane is revoked and Zebra
doesn't have access anymore (and neither does the sock puppet).

But if the legal department verifies that Zebra Copy is a genuine
company that provides services, it gets its own membrane and all
caretakers are migrated there. Ideally, the revocation capabilities to
those caretakers should remain in a manager shell for the service
after Bob's access as a manager is disabled, for the next manager to
get. (or for other managers to use even while Bob is still there)

As the sock puppet won't get verified by HR or legal, it won't get its
own membrane.

Tentatively,
Pierre Thierry
--
pie...@nothos.net
OpenPGP 0xD9D50D8A

[Alan Karp]

On Wed, Dec 28, 2022 at 7:51 AM Pierre Thierry <pie...@nothos.net> wrote:

Scribit Alan Karp dies 26/12/2022 hora 11:08:
> What is to prevent some of those delegations being to a sock puppet?

And if we simply revoke all delegations made by Bob, it means every
"worker bee" in his former service now needs to reacquire
capabilities.

If they can do that easily, what would prevent the sock puppet to do
the same?.

So isn't the real question more about how to prevent Bob from creating
a sock puppet?

If there is a service that can authenticate genuine agents of the
system and extract their capabilities from Bob's membrane, you can
disable his membrane when he leaves the service/company.

Similarly, in the original scenario in which Bob only has access to a proxy that does the actual delegations, the proxy can do the vetting you propose.  In that case, sock puppets never get any capabilities.  The difficulty is distinguishing a legitimate sock puppet, such as one Bob sets up so a service he runs has only some of his authority, versus a malicious one that Bob sets up to use as a back door if he gets fired.  It can be done, but the job is not a trivial one.

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

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/Y6xmBBDi727wH6i5%40viper.autogriff.com.

[Ben Laurie]

On Wed, 28 Dec 2022 at 16:20, Alan Karp <alan...@gmail.com> wrote:

On Wed, Dec 28, 2022 at 7:51 AM Pierre Thierry <pie...@nothos.net> wrote:

Scribit Alan Karp dies 26/12/2022 hora 11:08:
> What is to prevent some of those delegations being to a sock puppet?

And if we simply revoke all delegations made by Bob, it means every
"worker bee" in his former service now needs to reacquire
capabilities.

If they can do that easily, what would prevent the sock puppet to do
the same?.

So isn't the real question more about how to prevent Bob from creating
a sock puppet?

If there is a service that can authenticate genuine agents of the
system and extract their capabilities from Bob's membrane, you can
disable his membrane when he leaves the service/company.

Similarly, in the original scenario in which Bob only has access to a proxy that does the actual delegations, the proxy can do the vetting you propose.  In that case, sock puppets never get any capabilities.  The difficulty is distinguishing a legitimate sock puppet, such as one Bob sets up so a service he runs has only some of his authority, versus a malicious one that Bob sets up to use as a back door if he gets fired.  It can be done, but the job is not a trivial one.

The underlying problem, it seems to me, is that capabilities, in practice, are code. We can't, in general, know what code does (so far), so ... we can't, in general, know what capabilities do.

"Fixing" this problem would take away one of the joys of capabilities - i.e. that you can express *any* policy that can be computed. I'm not sure that's a good idea.

The other joy, of course, is avoiding confused deputies. Talk of namespaces, therefore, worries me, because that's how confused deputies come about.

One thing you could do to make it less painful is to separate at least some of the policies from more general code and express them in ways that make them easier to control. KeyNote (https://www.mattblaze.org/trustmgt/kn.html) is an interesting approach, I've always thought - I've even used it a couple of times. I once wrote an Apache KeyNote plugin, in fact - I still think that was a good idea.

A colleague at Google is experimenting with authorization logic (https://www.cs.cmu.edu/~fp/talks/fcs05-talk.pdf)  for similar reasons.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0u4qtobg9uVqL67%3DkBMdQbjFR1x5%3D06AZYfSKYkzyRPw%40mail.gmail.com.

[Alan Karp]

Keynote sounds a lot like the PEP-PDP approach.  Is that right?

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CABrd9SSfe2zNpDGRwfWV8uO21OiuKFOg52MZAVws9-W%3D_D2NLQ%40mail.gmail.com.

[Ben Laurie]

On Wed, 28 Dec 2022 at 17:17, Alan Karp <alan...@gmail.com> wrote:

Keynote sounds a lot like the PEP-PDP approach.  Is that right?

I don't think so.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0NdL-bhhc_4YvMhm1TJzgsOAH0sbaD49Pn2hy%3DXzS48A%40mail.gmail.com.