[cap-talk] A dabblers take on security

[Jonathan S. Shapiro]

On Wed, 2008-02-06 at 13:18 +0000, William Pearson wrote:
> 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...

For the sake of discussion, let us assume a current-generation AMD64
machine with my TLB accessor enhancement. Such a machine provides direct
support for (2^48/2^12 = 2^36) capabilities per capability address
space. Since the capability address spaces are entirely managed by
software, there is nothing precluding the OS from concatenating them in
software if a larger space is required.

Running out does not seem like an urgent problem.

Similarly, it seems likely that a 64 bit address space is sufficiently
large that stealing three bits from the bottom of a pointer is not a
major issue.

> 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? 

This attack cannot escalate privileges. It can only create resource
pressure, and not if the accounting system is correctly implemented.

>  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.

My pointer proposal above does not introduce any indirection at all, so
I am not sure what is motivating your concern here.

> > > 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...

I fail to understand why this should be so. A capability is simply a
type-safe pointer. I look forward to your email on lazy managers.

shap