Capabilities
E uses capability based security to supply both strong security and broad flexibility without incurring performance penalties. Capabilities might be thought of as the programming equivalent of physical keys
E makes use of the Principle of Least Authority (POLA) to ensure that it gives no more authority that the other part needs.
In the real physical world, if you had to depend on children to fetch CDs, you would not use an ID badge. Instead you would use keys. You would give the child a key to the front door, and a key to the CD cabinet. You would not give the child a key to the gun vault. All current popular operating systems that have any security at all use the ID badge system of security. NT, Linux, and Unix share this fundamental security flaw. None come anywhere close to enabling POLA. The programming languages we use are just as bad or worse. Java at least has a security model, but it too is based on the ID badge system–an ID badge system so difficult to understand that in practice no one uses anything except the default settings (sandbox-default with mostly-no-authority, or executing-app with total-authority). The “children” are the applications we run. In blissful unawareness, we give our ID badges to the programs automatically when we start them. The CD cabinet is the data a particular application should work on. The gun vault is the sensitive data to which that particular application should absolutely not have access. The children that always run to get a gun are computer viruses like the Love Bug. In computerese, ID badge readers are called “access control lists”. Keys are called “capabilities”. The basic idea of capability security is to bring the revolutionary concept of an ordinary door key to computing.
The following is an example of a capability based system against the Melissa computer virus:
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.
You must consider some fundamental concepts before using capabilities:
- Pointer arithmetic is a security catastrophe. So, no C/C++ but ok to Java and Smalltalk.
- You can’t reach inside an object for its instance variables. So, no Python or Javascript but ok to Java and Smalltalk.
- No static mutable state. Java and Smalltalk fail here.
- Design the API to not leaking capabilities. Here the human brain could fail
More information here: http://en.wikipedia.org/wiki/Capabilities
E capabilities
E has no pointer arithmetic. E has no mutable statics. E has an API carefully thought out to prevent capability leaks. This would make it a capability secure language for single-processor applications. But E goes a step further. It takes the concept of a secure, unforgeable object reference and extends it to distributed objects: * The communication links are encrypted. Third parties cannot get inside the connection. * The objects are unfindable without a proper reference received (directly or indirectly) from the creator of the object. You must have the key to unlock the door. * The objects are authenticated. No object can pretend to be the object you are trying to contact.
E is automatically secure. References are secure. Remember POLA principle everytime you design a secure system.
E systems can still be attacked from below, by viruses granted authority by the operating system underneath the E world. Such attacks can only be prevented by completing the security regime, either with capability-based operating systems, or with computers on which only capability-secure programs are allowed. There is one open-source capability-based OS under development, at www.eros-os.org.
One form of attack that even E cannot defend against is denial of service (DOS). In a denial of service, someone simply swamps your system with requests, making your system unable to operate. Such attacks take many forms, but the key limitation in such attacks is this: such an attack can never steal your secret data or gain control of your sensitive operations. If DOS were the only kind of attack possible, the world would be a vastly better place.
Some other principles from Croquet Security Requirements Suggestions:
Minimize Authentication. Focus on Authorization. Authentication-laden systems are as user friendly as post-9/11 airport security systems. And they work about that well, too. The terrorists are far more likely to have their identification in order than the rest of us.
Do Not Prohibit What You Cannot Prevent. The main purpose of this advice is to prevent you from looking like a fool after you’ve been circumvented.
Embrace Delegation. People must delegate to succeed. So they will delegate despite your most ridiculous efforts. Relax, enjoy it. Help them. And while relaxing, re-read the earlier, “do not prohibit what you cannot prevent.”
Bundle Authority with Designation. This makes security user-friendly by making the security invisible. Only possible after you stop wasting your effort on authentication all the time.
