No magic bullet for security

Some say that open source software is inherently secure because the "open source process" makes it so. Wrong. Open source software, and the collaborative culture that surrounds it, have surely enhanced Firefox's security. But also necessary is a disciplined approach to reducing the attack surface area. And one of the most vocal and visible proponents of that discipline today is ... Microsoft.

The recent turnaround of the company's IIS (Internet Information Services) Web server was remarkable. Version 5 was security-challenged and widely deprecated, version 6 is rock-solid and arguably safer than Apache. If the long-delayed refresh of Internet Explorer has been rethought along similar lines, it could prove to be an excellent platform on which to safely tap into the power of AJAX -- which, after all, Microsoft invented.

The open source and Microsoft cultures can complement one another. I hope they will. If we're going to safely enjoy the benefits of AJAX-style computing, we'll need all the help we can get. [Full story at InfoWorld.com]

In response to this column several folks, including Patrick Logan, have referred to the capability-based security model which is implemented in the E programming language. This model, insofar as I understand it, organizes permissions in such a way that the principle of least privilege is always in force. The introduction paints this picture:

Suppose your mail system was written in a capability-secure programming language. Suppose it responded to a double-click on an attachment by trying to run the attachment as an emaker. The attachment would have to request a capability for each special power it needed. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard.

Next, Melissa would have to ask you, "Can I have a direct connection to the Internet?" At this point only the most naive user would fail to realize that this email message, no matter how strong the claim that it came from a friend, is up to no good purpose. You would say "No!"

And that would be the end of Melissa, all the recent similar viruses, and all the future similar viruses yet to come. No fuss, no muss. They would never rate a mention in the news. [Introduction to capability-based security]

The capability literature seems to suggest that none of our conventional languages or environments can be straightforwardly aligned with the capability-based model, and if that's so, it's hard to see how these ideas could ever thrive outside the research lab. Of course both Java and .NET do offer evidence-based code access security mechanisms, and I wonder whether, or to what extent, these map to what the capability folks are talking about.

Either way -- that is, in the unlikely event that we reinvent everything from the ground up, or in the more likely scenario that we escalate our use of virtual machine runtimes (JVM, CLR) that make the principle of least privilege increasingly hard to violate -- we come back to the Melissa example. The person in this example won't want to interact with a hypothetical capability-based system any more than with, say, ZoneAlarm. And if broad delegation of power from humans to software is a necessary evil, I don't see any shortcuts or magic bullets -- we'll be sweating the details forever. Of course, I'd love to be wrong about that.


Former URL: http://weblog.infoworld.com/udell/2005/07/28.html#a1278