[Dev] Re: [Design] Obvious Scripting Security Notes

[Paul Snively]

On Sunday, November 3, 2002, at 12:21  PM, Mitch Kapor wrote:

> I would encourage a conversation on the dev list about how to do this 
> and still allow powerful scripting.

In truth, this isn't likely to be an issue, as it's hard to think of 
any scripting languages that don't meet the first four qualifications 
(the fifth qualification isn't strictly necessary, but actually makes 
certain security patterns far easier to implement). In particular, 
Python itself meets all five qualifications, as does, IIRC, JavaScript. 
This basically means that scripts in these languages are immune to the 
classic security problems arising from buffer overrun exploits, as well 
as more sophisticated attacks that are possible when you can cast, e.g. 
an integer to an object reference.

> I don't see how Chandler can NOT not do HTML email.  Plug-ins are 
> vital as well.
>
*sigh* OK; I was afraid of this. I have to say that if you accept this 
combination as  a pair of requirements, and probably also insist on 
supporting JavaScript in the HTML with backward compatibility with MSIE 
and/or Outlook, then you will inherit the complete lack of any kind of 
security focus that MSIE and/or Outlook suffers from, plus you'll open 
new vectors of attack to the extent that this gaping hole is embedded 
into the rest of Chandler.

> I know it's a challenge, so let's start working on it.

Quite right. Perhaps we should begin by drafting as comprehensive a set 
of use-cases for Chandler as possible, and articulate some functional 
requirements. For example, I wouldn't have expected "HTML e-mail" to be 
a requirement; as far as I can tell, HTML e-mail is used only for spam, 
and that primarily so that web-bugs can be used to track who actually 
reads the e-mail. Supporting browser plug-ins makes it quite literally 
impossible to make any strong security claims at all. Does Chandler 
really need this? If so, why? Perhaps more saliently, how do we 
prioritize Chandler's feature requirements against its security 
requirements?

When I responded earlier to Andy, I urged him to take a look at 
<http://www.erights.org>, download the latest version of E, and take 
the CapDesk application for a spin. I'd actually like to urge EVERYONE 
to do that so that they can see a distributed application with security 
baked-in from the outset, without sacrificing usability, in action. 
Then please read <http://www.sims.berkeley.edu/%7Eping/sid> and 
<http://www.erights.org/elib/capability/ode>. There's been a tremendous 
amount of time and energy invested in enabling, as Mark Miller 
eloquently puts it, "patterns of cooperation without vulnerability." 
This sounds like exactly what Chandler wants. If, however, we don't 
make any break with past designs that guarantee lack of security, then 
we will abdicate the right to be surprised when Chandler exhibits the 
same degree of vulnerability.

I should add that I believe it's possible to have most of our cake and 
eat it, too: we can certainly render HTML e-mail. We can even support 
JavaScript. We should just be prepared to make it possible to apply 
flexible security policies to JavaScripts and make the defaults tight 
(e.g. by default, a JavaScript can't read the contents of a directory 
on your hard disk, let alone open a file). But before we can do any of 
this, we need a principled way of talking about capabilities and their 
management. Thankfully, we don't have to invent this: the links I've 
already provided give tons of background, and even working code, that 
helps address issues like these. What we need to do is map those 
concepts to Chandler's requirements with the aim of crafting an 
extremely useable system that is secure as a largely-transparent 
side-effect of being usable. Put another way, security IS a usability 
requirement.

Best regards,
Paul