[e-lang] Threat model of capability-based systems
jcouv at microsoft.com
Wed Feb 23 17:13:30 EST 2005
Here's a link to the Microsoft threat modeling practices:
In short, it's about identifying as many threats as possible and giving
them risk scores based on some criteria (how easy the exploit is, what
is the damage,...). The criteria may not be universal; they just need to
be agreed on beforehand.
Using a managed runtime lowers the buffer overflow risk dramatically,
but doesn't eliminate it (the runtime might have a bug).
Also, I believe that EROS and COYOTOS are not implemented in E, so some
risks might apply to these OSes, that don't apply to applications
running in E.
Threat modeling is the only concrete way I know of evaluating the
security of a system. Although all the concepts behind E make a lot of
sense to me in terms of security, such a quantitative measure would
really prove the point that it is in fact more secure.
For example, although C# is managed, it doesn't follow capability
discipline, so that has to appear in the threat/risk matrix. Which risks
are mitigated by E but are not mitigated by C#/CLR? How much more secure
are the resulting applications?
From: e-lang-bounces at mail.eros-os.org
[mailto:e-lang-bounces at mail.eros-os.org] On Behalf Of Matej Kosik
Sent: Wednesday, February 23, 2005 1:35 PM
To: Discussion of E and other capability languages
Subject: Re: [e-lang] Threat model of capability-based systems
Julien Couvreur wrote:
> Was there any formal threat model done on existing capability system
> designs or implementations: E, EROS, COYOTOS?
> For example, if a buffer overflow was to happen, what is compromised?
> it all the capabilities held by the compromised object, vat or
I think that this your question can be answered easily this is my
Certainly E is not C/C++. Thus you can make your own experiments:
? var my_array := ["item1", "item2", "item3"]
# value: ["item1", "item2", "item3"]
# value: ["item1", "item2", "item3"]
# value: "item1"
# value: "item3"
# problem: <ArrayIndexOutOfBoundsException>
# - EList#get(int)
# . ["item1", "item2", "item3"].get(3)
# @ get/1: <-.e#:span::4:8::4:8>
# - EExpr#evalToPair(Scope)
# . e`my_array.get(3)`.evalToPair(<a Scope>)
# @ evalToPair/1:
Is it clear? You can have a capality to some array but this does not
grant you the possibility to access anything else but it elements.
Arrays in E are objects. Capabilities are not crude pointers. Not pieces
of memory. Until now I didn't find apparent security flaw in E. Play a
little with E and you will see it too.
I am not a capability expert so I cannot answer your other questions.
> How do the capability security concepts apply on existing hardware? Is
> there any hardware improvements (in the line of memory management,
> virtual memory isolation) that could mitigate some of the threats?
> Also, I'm still trying to get my head around the larger picture of
> capabilities. Some loosely connected questions:
> - Is there a example design for a large system such as the
> desktop or an email application? A comparison threat model might be a
> good thing, comparing a current and a capability-enabled design.
> - Could the concept of capabilities be used on the web (ex:
> amazon cart access capability, a credit card capability,..)?
> - What is the interface between the principal view of the
> (a user logs in with a password) and the capability view (that user is
> really just an entry point to a graph of capabilities)? Do the
> of identity or user almost disappear? Again could this be used on the
> web: no single sign-on problem, instead there is the problem of the
> accessing his capabilities from a secure storage (local or not).
> e-lang mailing list
> e-lang at mail.eros-os.org
e-lang mailing list
e-lang at mail.eros-os.org
More information about the e-lang