[cap-talk] solve CSRF by making references unforgeable, not unshareable

lists at notatla.org.uk lists at notatla.org.uk
Fri Mar 27 06:35:26 EDT 2009

"Karp, Alan H" wrote:

> > > One of Jed Donnelley's systems (DCCS?) encrypted sparse
> > > capabilities with a key not available to the process holding
> > > them in order to prevent leakage when people read dumps.
> > 
> > If something's not sparse what stops someone changing it?
> They are sparse capabilities.
> > 
> > I thought that was the idea beind encrypting the tokens
> > in this example.
> >     http://nob.cs.ucdavis.edu/bishop/secprog/robust.html
> The string "encr" doesn't show up on that page.

Well spotted - that's what I get for relying on old memory
and not re-reading the page.

I'm referring to the transformation from pointers to tokens that
allows tokens to be safely disclosed outside the library functions.

    If we make the token a pointer to a structure, the user will be
    able to manipulate the data in the structure directly. Hence we
    need some other mechanism, and indexing into an array is the
    obvious solution. However, if we use simple indices, then the
    user can refer to queue 0, and have a high degree of certainty
    of getting a valid queue. So instead we use a function of the
    index such that 0 is not in the range of the function. Thus,
    we will represent the queues as entries in an array of queues,
    and the token will be an invertible mathematical function of
    their index.

More information about the cap-talk mailing list