[cap-talk] A dabblers take on security

[William Pearson]

On 06/02/2008, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> On Tue, 2008-02-05 at 20:42 +0000, William Pearson wrote:
> > Ocap has the negatives of
> >
> > Increased storage space for longer capabilities over normal pointers
>
> It is not obvious that this is correct. Indeed, if the architecture
> (perhaps in common with a conforming runtime) can ensure memory safety,
> it is not obvious that any change to pointers is required at all, unless
> it is possibly re-using the least three bits for a type code (this
> assumes that capability-named objects are doublewords at minimum, which
> does not seem unrealistic).

For some scenarios this is probably the case. It depends how quickly I
am invalidating the capabilities. I might use up the capability space
quite quickly naturally, depending upon the complexity of the system.
With a smallish capability space is there also potential for a process
to attack the system by creating capabilities and invalidating them
quickly to try an escalate its privileges? I suppose you could tie the
sweeper that clears out old invalid capabilities to the capability
space getting full in some fashion. Hmm. I'm also not a fan of the
indirection this causes. I'd prefer the capability to be meaningful in
itself (as in the concatenation I suggested). I'll read up on the eros
implementation to get a better idea of the trade off.

> > Spreading the capability to all parts of a process that need it
>
> No worse than spreading pointers.

In my scenario spreading pointers only has to be done once, where as
spreading capabilities would have to be done many times, or a layer of
indirection added. You would have to reacquire pervasive permission
many times as well, but this can be done relatively simply.

I'll explain the type of scenario I am interested in, and why so many
invalidations are required for what I want to do, in another email
titled the lazy manager scenario.

  Will Pearson