Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> Sent: Tuesday, July 25, 2000 3:37 AM
> To: Karp, Alan
> Cc: 'Mark S. Miller'; 'Jonathan S. Shapiro'; e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> "Karp, Alan" wrote:
> > 
> > Ahh, so that's the difference.  I was assuming that, as a 
> holder of the
> > decrement capability, I see an object that can only be 
> decremented.  In this
> > view, any increment is a side effect outside the object 
> model.  You are
> > saying that a holder of any of the foreseen facets is 
> automatically aware of
> > all the other foreseen facets, or at least those with 
> visible effects.
> > Thus, any action appearing in a foreseen facet is within 
> the object model.
> > 
> > This point raises an interesting question.  Knowing that an 
> operation is
> > possible makes a certain class of attacks possible.  Hence, 
> we want to
> > institute a policy of least information.
> 
> Umm ... security that relies on people not knowing things is generally
> bad - your threat model should generally assume that the 
> attacker is in
> full possession of the facts about the system (after all, he wrote it,
> didn't he?).

You don't want to rely on secrecy, but you don't want to make the attack
easier than you have to.  Failed login attempts used to result in one of two
error messages, "No such user" or "Bad password".  That let an attacker
separate the problem of guessing userids from that of guessing passwords.
Today, you only get a "Try again" message.  

In general, the best response to an unauthorized request is no response at
all.  However, legitimate users make mistakes, so some information should
probably be returned.  In e-speak Beta 2.2, an attempt to access a resource
you don't have access to resulted in a "Does not exist" response.  In
e-speak DR 3.0, any request accompanied by an invalid or incorrect
capability is silently ignored.  Neither system relies on withholding
information for security; it's done only to make attacks more difficult.

> 
> >  On the other hand, it's not nice
> > to surprise your programmers, so we also want a policy of least
> > astonishment.  These policies are often in conflict, and 
> care is needed in
> > deciding which one to honor.
> 
> Nope. The latter is the only one worth considering.
> 
> Cheers,
> 
> Ben.
> 
> --
> http://www.apache-ssl.org/ben.html
> 
> Coming to ApacheCon Europe 2000? http://apachecon.com/
> 

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278