Re: Redirects and Revocation in a Capability Filesystem

On Fri, November 7, 2014 19:37, David Barbour wrote:
> On Fri, Nov 7, 2014 at 8:39 AM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:
>
>> /fs2/$r1/Bob ->  dead link to /fs1/bob:r2 (r2 not available in r1 view)
>>
>
>> The base idea is that the '..' implied by the extended attribute usage
>> can
>> only ever be used in an amplify+filter-view operation by the second
>> file-system.
>
>
> I see. You're sacrificing expressiveness in order to avoid DAGs. I'd
> rather
> avoid this second-class treatment of redirects. I imagine it would create
> complexity for applications, dealing with special corner cases and
> workarounds.
>
> So, how do you ensure that /alice/Bob uses a different attribute than
> /bob/Alice?
>
>
>> /cap/ would be the mountpoint of your file-system
>>
>
> Why wouldn't /cap/ just itself be a capability? Seems to me we don't need
> to pretend our ideal-world filesystems are mounted in ext-3 or whatever.
> :)
>
>
>> for a moment skip the delegation process itself. At one point we end
>> up with a revokable link in the carol directory
>
> $link2=revokableref(
>
>
> I feel that skipping the delegation process has hindered your
> comprehension. Consider: If you did have a "revocableref" function, you'd
> need to return TWO capabilities.
>
>     $revoker,$ref = revokableref(destination)
>
> At which point you'd need to somehow save the revoker for future use.
> Atlernatively, you could create a revoker ahead of time, and associate it
> with the revocable on construction:
>
>    $ref = revocableref(revoker, destination)
>
> Use of a redirect to model revocables avoids this conundrum simplify this
> by reifying the (revoker,destination) pair as an object in the filesystem.
> A redirect, of course, also permits other forms of useful intercession,
> such as transparently changing the destination.
>

Ah, I considered something more like:

Alice:
* destination::revokername =  revocation_point(destination,revokername)
* $ref = overlay_attenuation(destination::revokername)
* Some form of communication to share $ref with Bob)

Bob:
* source = $ref

So for example for Alice:
* xattr -w "revoker:forbob" "" /home/me/foo.txt #creates a revocationpoint
* xattr -r "revoker:forbob" /home/me/foo.txt #returns attenuated $ref
..
An than if we want to revoke:

* xattr -d "revoker:forbob" /home/me/foo.txt

And for Bob:

* ln -s /redir/a8hg6t330plnqxgk852gavh /home/me/Alicefoo.txt


>
>>
>> A think I see a glimmer of the source of my disconnect. In the design
>> I've
>> been using, there is no such thing as a top node in the graph
>
>
> This isn't an impediment. The technique works just as well for a forest,
> or
> even for a fully cyclic graph, as it does for a tree. At essence, all
> we're
> doing is keeping information about *a path*, and validating that this
> *path
> still exists* before granting access to a resource.
>
> For efficient performance, you would need an index that tells you for each
> location to which other locations they are connected. I.e. you can't be
> decrypting directory files or hashing pet names on every step. This index,
> if exposed to users, would give them some information about connectivity
> that you do not wish them to have.
>
> And, of course, you'd also need a larger filtering factor at the start -
> e.g. a filtering factor of about four billion for the first step, since
> you
> don't have a common root. Instead of an initial branch filter factor of
> 256
> (monospaced):
>
> M             auth code
>  AAAAAAAA     path elem
>   BBBBBBBB    path elem
>    CCCCCCCC   path elem
>     DDDDDDDD  path elem
>         HHHH  hmac
>
> You might tweak it as follows:
>
> M                auth code
>  AAAAAAAA        path elem
>      BBBBBBBB    path elem
>       CCCCCCCC   path elem
>        DDDDDDDD  path elem
>            HHHH  hmac
>
> In general, this method is highly tunable. I'm thinking I might support
> tunable branch-filtering factors on a per-directory basis.
>
>
>>
>> As a result for me operations such as path resolution and (single)
>> attenuation are CPU bound and relatively cheap
>
>
> Well, sure. If I didn't want to bother with revocability, which is perhaps
> THE most important attenuation pattern for secure interaction design, then
> I also would have very cheap resolutions - just a simple auth code, a
> GUID,
> and an HMAC. Or I could use Rumpelstiltskin hash trees by squeezing the
> lattice of auth codes into one linear chain of secure hash operations.
>
> But I think revocability - more generally, giving temporal attenuation the
> same first-class treatment as spatial attenuation - is important enough
> that I'm willing to take a performance hit in terms of inspecting an
> index.
>

How much are you willing to pay in performance and storage? And how does
your solution scale in these respect?
If you are willing to take the (O(N)) performance (with N being the number
of revocation points in a path) and (O(NlogN)) storage hit (with N being
the upper bound of covered by a revocation point), you could use
Rumpelstiltskin hash trees with extended attributes as I described. For me
these scaling specs are not particularly appealing, especially as apart
from the big O scaling issues, for small files and directories even a
single revocation point already adds up to almost 400% of disk IO
overhead.  What kind of price can be expected from your solution in this
respect? Is it better than my O(N) performance and O(NlogN) state?

Rob