Negative capabilities

[Matt Rice]

I was thinking about Alan's negative capabilities again yesterday as
discussed in the creeper thread,
and wanted to circle back to this in its own thread, and try to put my
finger on exactly why
I have some concern regarding negative capabilities...

On Sat, Jul 22, 2023 at 10:27 PM Alan Karp <alan...@gmail.com> wrote:
>
> I was concerned that an admin might accidentally give a powerful capability to a guest, so I introduced negative capabilities.
> A negative capability for an object in your c-list would prevent you from invoking that object even if you had a capability
> to the object in your c-list. The nice part is that you can delegate without worrying if you might be violating some policy.
> You still need a way to express who gets which negative capabilities

My assumption here is that this restricts the ability to invoke a
capability but does not restrict the ability to grant a cap to someone
who lacks
a negative capability, thus a guest cannot invoke it, but may be able
to transfer it to someone who can invoke it.
overly dramatic situation: Bob is given a dance-card and a negative
launch-the-nukes capability. Somehow he obtains a launch-the-nukes
capability.
But cannot invoke it. He asks Carol (who has no negative cap) to
invoke his dance-card, and gives her his launch-the-nukes capability.
Carol's tacit assumption is that Bob is a guest who nobody would grant
such a dangerous capability to.

An obvious fix to this situation is to provide a filter on channels
similar to those mentioned in the star-property solution papers that
restrict which capabilities that Bob himself can transfer to those for
which he has no negative capability. Given the need for that it makes
more sense to me to cut out the invocation part, and instead use that
same mechanism to filter the channels through which Bob receives
capabilities. That is I kind of feel like even with negative
capabilities, there is still a need for filtering channels and with
filtering channels, you probably don't need negative capabilities and
no longer have situations similar to those described above. Then if
there is still a need for Bob to hold capabilities which require more
authority than he himself wields to be invoked -- such things require
some synergistic effect in coordination with capabilities Carol holds.

I don't recall voicing any tangible justification for my skepticism of
negative capabilities in the previous thread, this is all I really
have to say on the matter & hopefully rectifies that lack...

[Alan Karp]

On Mon, Aug 14, 2023 at 10:42 PM Matt Rice <rat...@gmail.com> wrote:

I was thinking about Alan's negative capabilities again yesterday as
discussed in the creeper thread,

...

My assumption here is that this restricts the ability to invoke a
capability but does not restrict the ability to grant a cap to someone
who lacks
a negative capability, thus a guest cannot invoke it, but may be able
to transfer it to someone who can invoke it.

Your assumption is wrong.  There are two options.  Never put a capability in the c-list if there's a negative capability for it, or put it in the c-list but treat the slot as empty when it is named.  (The Client Utility mechanism was quite different.)  However you do it, the trick is to make the capability unnameable.

--------------
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/CACTLOFrVqSwjER1Qr8fdnpJ13DDbqem358-4KnkJrQeNicpYDQ%40mail.gmail.com.

[Matt Rice]

On Tue, Aug 15, 2023 at 5:53 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Mon, Aug 14, 2023 at 10:42 PM Matt Rice <rat...@gmail.com> wrote:
>>
>> I was thinking about Alan's negative capabilities again yesterday as
>> discussed in the creeper thread,
>> ...
>> My assumption here is that this restricts the ability to invoke a
>> capability but does not restrict the ability to grant a cap to someone
>> who lacks
>> a negative capability, thus a guest cannot invoke it, but may be able
>> to transfer it to someone who can invoke it.
>
>
> Your assumption is wrong. There are two options. Never put a capability in the c-list if there's a negative capability for it, or put it in the c-list but treat the slot as empty when it is named. (The Client Utility mechanism was quite different.) However you do it, the trick is to make the capability unnameable.
>

I didn't respond sooner, largely because I tend to view the first
option roughly equivalent to some kind of filter I'd mentioned in my
original message, as such I don't really have any comments on that
option.
some thoughts on the latter option "Put it in the c-list but treat the
slot as empty when it is named". With a filter I would approach this
by having a side buffer where filtered elements go.
otherwise only non-filtered elements are delivered, but (someone)
could still access the side-buffer via a separate capability.

I am unsure what putting them in the c-list but treating the slot as
empty is useful for.
In particular if you then allow revocation of the negative-cap,
allowing the slot to afterwords be named it turns revocation into an
authority granting operation.
There are certainly ways to repair that (irrevocable negative caps and
negation negation caps which can then be granted as an alternative to
revocation).
But those repairs seem much more complex than just ensuring that if
Bob shouldn't have some specific kind of cap, one sent to them cannot
actually reach the destination (or just takes a potentially infinite
amount of time to reach the destination).

Presumably I may be missing a use case for actually placing these
negated caps in the c-list, such as using different views of the same
c-list with various sets of negative capabilities.
That wouldn't have an impact on any important properties of the system
like revocation here. Anyhow, it seemed somewhat worth mentioning
this specific obscure case.

[Alan Karp]

You are indeed missing use cases.  

One is incremental permissions.  You could initially give a user session a small set of permissions.  If they can get their work done, you've reduced your risk.  If they can't, they can ask for the next level, which you give them by removing the negative capability for that level from the c-list.  The alternative is adding the necessary capabilities on request using something like the side buffer you mention, but I think that's harder to manage.

Note that I said "removing the negative capability," not "revoking the negative capability."  It may be convenient to use the same negative capability for many users, much as you would a role.  For example, you can have one negative capability that you put in the c-list of all non-accountants.  

In another example, you can make the positive capability for customer A's data be a negative capability for customer B's, which gives you a form of Chinese wall.

--------------
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/CACTLOFoU8TzzqiG-_aJD3togk-s68kJyiTtynPh9XucfgrcwJA%40mail.gmail.com.

[Jonathan S. Shapiro]

A few suppositions about Alan's negative capabilities - I apologize that I haven't read his original note; I'm inferring the concept from the discussion in this thread.

1. In some environments, propagation will be asynchronous. In semi-connected environments, propagation may be delayed for quite a long time. These concerns need to be considered in constructing the application. It is possible to construct protocols in which any outstanding negative capabilities are transmitted before the corresponding positive capability can be invoked.
2. Combinations of negative and positive permissions have notorious algebraic problems. The fact that negative capabilities are "all or nothing" makes them a special case of negative permissions that does not have unpleasant algebraic behavior, except that negative capabilities on negative capabilities are an algebraic nightmare and should be excluded.
3. A small variant on negative capabilities (intended to co-exist) would be canceling capabilities - the difference being that their effect is durable and irrevocable. Canceling capabilities on negative capabilities work fine, and are algebraically sane.

Collectively, this moves us in the direction of something that is already done at the implementation level in CapTP. A client can "drop" a capability or a promise, signaling to the server that the corresponding slot in the pending promise table[s] can be reclaimed. But destroy operations require that the service implementing the object be able to send "death notices" to all clients wielding that capability. To squelch round trips, this becomes something akin to "become undefined", by which I mean "become" in the SmallTalk sense.

Anyway, my main point is that there are pleasant connections to CapTP hiding in here.

Jonathan

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

[Alan Karp]

On Mon, Sep 18, 2023 at 8:00 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

A few suppositions about Alan's negative capabilities - I apologize that I haven't read his original note; I'm inferring the concept from the discussion in this thread.

1. In some environments, propagation will be asynchronous. In semi-connected environments, propagation may be delayed for quite a long time. These concerns need to be considered in constructing the application. It is possible to construct protocols in which any outstanding negative capabilities are transmitted before the corresponding positive capability can be invoked.

The only way I could make negative capabilities work was to put them in the c-list of the local proxy of the remote requester.  In that case, there are no asynchrony issues.  Of course, that only works if you have the concept of a "session" to attach the c-list to.

1. Combinations of negative and positive permissions have notorious algebraic problems. The fact that negative capabilities are "all or nothing" makes them a special case of negative permissions that does not have unpleasant algebraic behavior, except that negative capabilities on negative capabilities are an algebraic nightmare and should be excluded.

Fortunately, having negative capabilities on negative capabilities never occurred to me.  I'm afraid I would have tried to implement them had I thought of it.

Anyway, my main point is that there are pleasant connections to CapTP hiding in here.

I had no idea. 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMZakK6Zd38cyX%3D7PzK4Jm7k_QkohcjhMLV1%2B8PXpycxw%40mail.gmail.com.

[Christine Lemmer-Webber]

Matt is right. Alan's negative capabilities approach doesn't work for
the same reasons described on the prohibiting delegation page of yore:

http://www.erights.org/elib/capability/delegations.html

> Alice gives Authority to Bob. Mallet wants that authority, but Alice
> wants to deny this authority to Mallet. There are two yes/no
> questions, corresponding to the two question marks above.
>
> - Are Bob and Mallet supposed to be able to communicate?
> - Does Bob wish to give Mallet the authority, despite Alice's wishes to the contrary?

It's the same thing.

[Alan Karp]

On Mon, Oct 2, 2023 at 8:22 AM Christine Lemmer-Webber <cwe...@dustycloud.org> wrote:

Matt is right.  Alan's negative capabilities approach doesn't work for
the same reasons described on the prohibiting delegation page of yore:

  http://www.erights.org/elib/capability/delegations.html

That is correct.  Negative capabilities are only good for preventing mistakes.

Enterprise policies are complicated, and they change all the time.  You won't have security if you need everybody to know all the policies all the time.  Negative capabilities are a means of reducing the likelihood of a policy violation.  For example, on Friday, you are a contractor with permission to see certain documents.  On the following Monday your contract is different.  A negative capability can prevent policy violations by those not aware of the change.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/877co5jbgu.fsf%40dustycloud.org.

[Christine Lemmer-Webber]

Ah, ok. If the issue is another voluntary oblivious compliance example,
then yes it could work.