View source

[[Category:Walnut|4]]

===<span class="e">E</span> Capabilities===

<span class="e">E</span> has no pointer arithmetic. <span class="e">''E ''</span>has no mutable statics.<span class="e">'' E ''</span>has an API carefully thought out to prevent capability leaks. This would make it a capability secure language for single-processor applications. But<span class="e">'' E ''</span>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.
* No object can pretend to be the object you are trying to contact because identity cannot be hijacked.

These aspects of<span class="e">'' E ''</span>protocol can be understood better by looking at the URI that identifies an<span class="e">'' E ''</span>object to other objects outside its own vat.

====A closer look at E capability URIs====

{| style="float: right; width: 2in; border-style: inset; border-width: 3;background-color: #FFFF99; font-size:80%" 
|
The whole <span class="e">E</span> approach to security is disorienting to anyone steeped in traditional computer security lore. On the other hand, anyone with a background in object-oriented programming will find it to be a natural extension of the OO discipline. Another entire book is needed on the philosophy of security exemplified by object capabilities and <span class="e">E</span>. [http://minnow.cc.gatech.edu/squeak/3770 The closest thing to such a Philosophy of Security known to the author is a requirements document] for the shared virtual 3D world [http://croquetproject.org/ Croquet]. Croquet needs to be both very user friendly and very secure, and so requires the kind of seriousness that object-capabilities enable. <br /><br /> A brutally abbreviated list of points from that document includes: <br /><br />'''No Passwords, No Certificates, No Certificate Authorities, No Firewalls, No Global Namespaces.''' POLA, pet names, and other related techniques described here supplant them all.<br /><br />'''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. <br /><br />'''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.<br /><br />'''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."<br /><br />'''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.
|}

====Security as an inexpensive lunch====

There is no such thing as a free lunch, but this does not rule out the possibility of lunches at bargain prices. When programming in<span class="e">'' E''</span>, you are automatically working in a capability secure environment. All references are secure references. All powers are accessible only through capabilities. Making an<span class="e">'' E ''</span>program secure is largely a matter of thinking about the architecture before you code, and doing a security audit after you code. When designing and auditing you use a small number of principles for scrutinizing the design:

====Principle of Least Authority (POLA) for Computer Programs====

The Principle of Least Authority (known henceforth as POLA), which has been used by human beings instinctively for thousands of years, translates to computer programs fairly straightforwardly: ''never give an object more authority than it needs''. In particular, if an object may be running on a remote untrusted machine, think very carefully about the minimum set of authorities it needs, and give it capabilities only on ''facets'' (described later) that ensure it gets no more. A simple word processor needs read and write access to the one file it is being used to edit, and it needs read-only access on all the system fonts. It does not need any access to anything else. Do not give it access to anything else. If it asks for something else, it is lying to you, and you should not trust it.

====Principle of Hardware Software Ownership====

When developing software, remember that the person who controls the hardware always, at the end of the day, controls the software. Hence, if you send someone a piece of a distributed program to run on their own equipment, that person totally and utterly owns everything that resides on his machine. They can modify the code you gave them, or rewrite it from scratch yet make it look from the outside like it is identical. You must therefore think carefully about what features of your system you really trust on that remote machine. A key feature of E that enhances its reliability is that objects which are manufactured in a particular vat remain resident in that vat, so that the objects remain as reliable as the objectMakers used to produce them. Only ''transparent immutables'' (immutables that don't encapsulate anything) actually move across computational boundaries.

Many people have made the error of believing this principle of hardware ownership can be circumvented. At the time of this writing, the music recording industry is throwing away truly fabulous sums of money on schemes that assume they can somehow control data after it has arrived on a user's own hardware. Microsoft is busily developing Palladium (uh, I mean, NGSCB). Intel is busily developing TCP (uh, I think they changed the name to La Grande). Their fate has already been foretold in the fate of the popular game Diablo I: authoritative representations of data were allowed to reside on user computers, assuming that the object code was too difficult to understand to be hacked and that the Diablo client code would always behave as the designers intended. They were 99% correct, which in the computer security field means they were 100% wrong. Today, 99% of the people who hack Diablo I don't understand the object code. But somewhere some single individual figured it out and posted the result on the Web. Now your grandmother can sabotage shared Diablo I games as quickly and easily as the most accomplished hacker in history. For Diablo II, the developers had learned the lesson. Authoritative information is stored only on the server, giving them the beginnings of true security.

Not only does hardware own the software, so too does the underlying operating system. As we have stated repeatedly here, <span class="e">''E''</span> enables the construction of extremely secure computing systems. However, <span class="e">E</span> systems can still be attacked from below, by viruses granted authority by the operating system underneath the <span class="e">''E''</span> 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 [http://www.eros-os.org www.eros-os.org].

====Denial Of Service Attacks====

One form of attack that even <span class="e">''E''</span> 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. Indeed, if only DOS attacks were possible, even most modern DOS attacks would fail, because the serious DOS attacks require that the attacker first gain control of hundreds of computers that belong to other people, by using attacks far more invasive and damaging than DOS itself.