[e-lang] Threat model of capability-based systems

[David Wagner]

Julien writes:
>Here's a link to the Microsoft threat modeling practices: 
>http://msdn.microsoft.com/security/securecode/threatmodeling/default.asp
>x?pull=/library/en-us/dnnetsec/html/thcmch03.asp 
>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).

If you're asking about E, E is a memory-safe language, so there should
be no buffer overflow risk, assuming the E interpreter is implemented
correctly.  Given this, I consider the risk of buffer overflows in
E code low enough that it is basically negligible compared to other
security risks.  If you look narrowly at resistance to buffer overruns,
I consider E in roughly the same equivalence class to other memory-safe
languages (like Java, ML, and the managed subset of C#).

I assume you are aware that buffer overruns are only a small part
of the larger security picture.  Eliminating buffer overruns is
absolutely necessary, but by no means sufficient, to ensure security.
It is depressing that C is so mired in such low-level, "Security 101"
type failures.  If all you do is write C code, it is easy to become so
focused on simply eliminating buffer overruns that you forget about all
the other security risks.

E aims to go significantly beyond that.  For instance, one of the main
goals of E is to make it easier to build systems that do a better job
of obeying the "principle of least privilege".  The support E provides
for this seems to be a big improvement on many previous programming
environments.  Because "least privilege" is such a significant factor in
determining the security of many applications, this is truly a big deal.

>From the questions you are asking, I hope you realize that the criteria
you have mentioned so far are somewhat shallow and only scratch the
surface when it comes to evaluating the security of an entire system.
(For instance, the document you referred to on threat modeling is useful
and well-written, but seems to be written primarily at an audience
of programmers who are not deeply experienced with doing this kind of
security analysis.  A number of the people on this list are much more
experienced at security and have been doing this for a long time.)  So,
I encourage you to not stop with a shallow set of criteria, but to look
more deeply as well.  Or, if you don't have time for deeper analysis,
I encourage you to seek out the opinions of experienced security experts
who have taken the time to look more deeply.

If you'd like to see a detailed independent review of the security of
one application built using E, take a look here:
  http://www.combex.com/papers/darpa-review/
We talk about both the security of the application itself as well as how
effective the E programming model was at helping secure this application.
I was one of the two reviewers, and I came away with a very favorable
impression.  Yes, I'm familiar with threat modeling, and we did plenty
of that as part of our security review.

I can't talk about EROS or COYOTOS.  They are totally different systems,
and I don't know enough about them to say much about them.