[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    [cap-talk] Re: "no copy" seen as wrong
From:       Eric Jacobs <eric () theeric ! com>
Date:       2005-11-30 1:17:29
Message-ID: 20051129191729.06bb8f17.eric () theeric ! com
[Download RAW message or body]

On Tue, 29 Nov 2005 16:09:57 -0800
Jed at Webstart <donnelley1@webstart.com> wrote:

> 
> I view the ability to communicate a possessed capability as an indivisible and
> indispensable property of the capability as a token of permission.  While there
> is indeed a very long history of efforts to provide copy restriction as
> a putative added value, in my opinion all such efforts have turned out
> to be counter productive - at least in the sense of wasting mechanism
> and providing no added value, but most often in terms of significant
> additional complexity and mechanism that results in confusion and
> binding constraints on the system whenever such a feature is used.
> For example, making it impossible to set up additional POLA domain
> divisions because an owned capability can't be shared (e.g. as I noted
> in the Iguana discussion).
> 
> What it comes down to is as simple as this.  As an active subject, any
> time I receive a capability, rather than invoke the capability myself I may
> choose to have another active entity (e.g. a process I set up with further
> restricted access) invoke the capability on my behalf.  This is a fundamental
> principle of POLA (e.g. as with plash, Polaris, etc.).  If I am unable to
> communicate "my" capability to the new subject, I can't do POLA.
> Oh sure, in general I am proxy the capability (e.g. as indeed with plash),
> but requiring such proxying is expensive and acts as a barrier to POLA.
> 
> It's just wrong.  It's anti-POLA.  Don't do it.

I think it does make sense to restrict delegation in certain
circumstances. For example, suppose I want to prove to you that I have a
certain identity. I can send you a capability that you can invoke to get
certain information about me. I can't just send you the information,
because then you'd have no way to authenticate it. By using a
capability, which is by definition unforgeable, you can gain that
assurance, because you can check with the authority that issued it
that it is authentic.

However, I would want your rights to my capability to end right there.
I.e., there is no excess authority granted to you if you may delegate
the cap to the issuer of that cap, because that issuer could create
arbitrary caps anyway. But if you can delegate it to anyone else, that
gives you the ability to impersonate me and that's definitely not POLA.

Bearing in mind that, although capabilities theory may be technically
correct that the whole concept of authenticating resources with respect
to an identity could be avoided in a system, it is still an established
paradigm and it's not going to go away anytime soon, it seems logical to
try to support POLA as best as possible in any as many extant
environments as possible; and as I see it, this is benefitted by having
(entirely discretionary) restrictions possible on the transfer of
capabilities.

Does anyone else see a different way to tackle this problem?

-Eric
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]