Contrary to the assumptions of most people- it is possible to create computer operating systems and programs that are immune to arbitrary attack by viruses and unauthorised access. In fact the foundational knowledge of how to build such a system has been known and applied for over thirty years. Unfortunately this knowledge has never been applied fundamentally and exclusively throughout the architecture of any mainstream Operating System.

The problem with modern mass deployed commercial OSes (such as Windows, standard Linux, etc) is that they all have very similar access control architectures. These architectures are built on Access Control Lists (ACLs) or comparable structures. They are generally all large gained access control systems at the level of user interaction. They cannot support the "Principle Of Least Authority" (POLA) while maintaining ease of use for the user. Consequently programs that run on these system require grossly excessive authority to be installed and to run.

A prefect example of excessive authority is your typical text editor. It normally runs with the large grained authority of the user running it-- this means that it has access to every file user owns and usually the same input/output ports that the user has access to. This requires that you to trust* the program to behave itself. You have no option when using the program other than hope the it was written with competence and in good faith. In typical use there is very little that you can do other than not use the program to prevent it from deliberate malicious access/modification of all your files. Similarly inadvertent detrimental access/modification to any of your files due to poor coding of the editor cannot be prevented. The program obliviously has dangerously excessive authority! This is the core problem with malicious code such as viruses and Trojans they likewise run with grossly excessive authority.

For a program, such as the above text editor, to be used securely it should only be able to access the files and IO ports that the user has specifically designated that the program is allowed to access AND NO OTHERS. This is known as the Principle Of Least Privilege (POLP).

The transitive sum of all possible access/actions that the program can perform is known as the program's authority**. An object's authority is usually greater than its privilege. For example with the text editor above-- if a running instance of the text editor has write privilege to a user configuration file such as the file that contains the address of the user's default page of a web-browser than it has the authority to cause the web-browser to display an arbitrary webpage. So even more important than limiting the privilege of an object within a system is limiting its overall authority. Limiting the authority of all code running on your system, whether purposefully malicious code or not, is adhering to the POLA discipline.

Although the POLA discipline is extremely hard to practice with mainstream systems, it can be applied effortlessly on systems that have an Object-Capability*** (ObCaps) architecture.

An object-capability [1] is an unforgeable reference to an object in a computer system. An obcap is freely copyable by its holder and freely transferable by its holder to any other entity, as long as the holder transfers it over a previously established communication channel.

The common analogy in the physical world is the common door key. Although, it must be made clear that the analogy breaks down with respect to the authorised communication channels: because in everyday life there is no restraint on who can talk to who, ie: everyone is allowed to talk to anyone. The most interesting and useful security properties of the object-capability model depend on the fact that capabilities can ONLY be passed from object to object along a previously established communication channel between the two objects. These channels may be for example actual physical network links or the arguments of a function or a shared limited access area in memory, etc.

The three most important reasons why ob-caps are so successful and useful for security are:

Firstly an obcap is all that is required to access the object that it references-- similar to a door key, all that you need to access a room is the key to the lock on the door. A doorlock doesn't care who you are or why you wish to access the room all it cares about is that you possess the key. Designation (the lock that the key points to) and authority (the ability to open the lock) are both carried exclusively be the key. The fact designation and authority are never separated in an obcap model is why it can easily handle many prickly access control dilemmas of traditional systems such as the confused deputy situation. Eg: it is trivial to make an obcaps based web site that is totally immune to cross-site scripting attacks.

The second reason why the obcaps model is so powerful is because it natively allows for the division of the system into extremely fined grained component objects: in fact it encourages the use of fine grained objects. The objects in a system that a cap can reference may be as fine as a single data page in memory, a section of code, a particular single function of a hardware device, the communication path between to objects or it can even be a reference to another obcap. But in addition, even though obcaps allow fine grained objects they are also used to reference large grained objects such as a whole program, a whole computer or even a whole computer network.

The third reason is because the ease that ob-caps allow for dynamic change of the connectivity network between the system's objects. An object can introduce any other two objects that it can communicate with to each other.  Once two objects have been introduce by a mutual third object they are free to communicate with each other and to further introduce other objects. Ie: the connectivity graph between objects is dynamically changeable by those objects similar to how we introduce our friends to each other in real life.

This allows systems to be built that may adapt to an objects access needs in a practical and orderly fashion without the intervention of an all-powerful central entity. For example, an ob-cap based OS has no need for the notion of a root/super user. In such OSes there is hardly any need at all for a system-administrator. It is possible to allow the users themselves to decide who should have access to the resources they control, such as their own files. A user is completely free to install whatever software they like whenever they like because they cannot affect any other part of the system unless they have the authority to access that part. The management of access to files/resources for cooperative collaboration among users is trivial and is best handled by the actual users.

The object-capability model has been deployed successfully at various system levels:

1) ObCaps are used exclusively in the fundamental security architecture of various OSes such as the KeyKOS system and its modern day descendants EROS, CapROS [2a] and Coyotos[2b].

EROS is a publicly available operating system that's confinement mechanism has been formally mathematically proven (as far as I know: it, along with its descents CapROS and Coyotos, are the only publicly available OSes -including both free and commercial- which have been proven).

Coyotos goes even one step further with the goal the being the first ever operating system kernel that's actual code (instead of just its architecture) is formally verifiable by a theorem prover. Basically it will be the world's most secure publicly available OS. Coyotos has been designed to be used in extremely high-security high-reliability situations such as medical equipment, nuclear systems, etc., and luckily for us it runs on commodity hardware and thus can be used as the kernel for desktop systems.

These Oses all have extremely fined grained security: every part of a computer, potentially right down to each page in memory, requires an ob-cap to access it.

You do not need to run virus protection on an ob-cap based OS! Even if a virus or other malicious software such as a Trojan is allowed to be installed and run on the system (and it can only be installed and run if the user deliberately/consciously allows it) it cannot do any damage since it has no authority to access any part of the system-- unless the user specifically further grants it access to a resource that that user has access to.

2) ObCaps have been applied at the language level in languages such as "E" [3]-- a language based on the Lambda Calculus similar to functional languages such as Haskell and Scheme . The ObCaps approach allows programmers to create extremely complex but secure programs which the programmers can guarantee interact with other programs in a defensibly secure way.  "E" also has many other features such a promise pipelining which means that programmers can create concurrent programs that they can guarantee to never deadlock.

3) ObCaps have been applied at the desktop level in projects such as CapDesk [4]. CapDesk demonstrates how easy it is to use a obcap based user interface system. Essentially it is no more difficult for a user to manage the fine grain control of their resources than what it is to use the common Windows GUI. Indeed most actions to operate a program are exactly the same, all that has changed is the background semantics of the action. For example, when you use the CapDesk File Dialog of a text-editor to open a file for editing you click on the file name as per a normal file dialog. What has changed is the meaning of the user's actions: normally when selecting a file for opening you are actually asking the text editor to a open the file out of all the files that it already has authority to open; but when using CapDesk you are granting the text editor the authority to open a specific file and only that file- the editor has no ambient authority to open any other file except the file that you designate.

4) ObCaps have been applied at the network level. ObCap based projects such as the Waterken [5] Server can be used to created secure mashups on the web.

However, having said all this-- people who use a capability systems are still prone to social engineering/confidence tricks/fraud. At the end of the day you cannot stop people from voluntarily giving criminals access to their resources if the users have been given the right to manage their own resources. This is similar how in the physical world how your can make a bank vault exceptionally resistant to thieves but you cannot stop people from simply being deceived by confidence tricksters into giving/donating their own money to them.

For these sorts of criminal activities capability security practitioners have developed protection mechanisms which help reduce a persons susceptibility to these attacks-- such as the anti-phishing petname web-address tool [6]. Unfortunately no system (capability or otherwise-- such as virus protection) will ever be completely immune to these sort of attacks. The best you can do is educate the user to make them aware of these types of criminal activities, to actively prosecute criminals and as a last resort if necessary revoke the user's right to manage their own resources and/or revoke the users access to their own resources.

# Please note: All of the above only applies to the software level. If there is a vulnerability/exploit at the hardware level than there is absolutely nothing that any piece of software will ever be able to do to secure your system.

[1] : 1 : http://en.wikipedia.org/wiki/Capability-based_security : the Wikipedia entry on capability based security
[1] : 2 : http://www.eros-os.org/essays/capintro.html : an introduction to capabilities

[2a] : http://www.capros.org/ : the CapROS web site
[2b] : http://www.coyotos.org/ : the Coyotos web site

[3] : http://erights.org/ : the home site of the E programming language

[4] : http://www.combex.com/tech/edesk.html : a web site describing CapDesk. It includes side-by-side comparison of a malicious Web-Browser running under CapDesk capability confinement, versus the same Browser with standard Windows/Unix privileges. It shows how CapDesk it doesn't suffer from the attack whereas the traditional OS does.

[5] : http://waterken.sourceforge.net/ : the Waterken Server web site

[6] : http://petname.mozdev.org/ : the Petname anti-phishing tool for Mozilla

*hopefully you gather the my intended meaning of "trust" from the context here. In computer security literature the meaning of "trust" varies form source to source. Although the author usually has a quite a distinct defined meaning in mind when using the word, unfortunately the meaning is often specific to the context/author of the article. There are various definitions given in technical dictionaries but regrettably some definitions conflict with others.

** The definition of "authority" is actively debated among capability experts, esp. on the captalk mailing list. It is generally agreed that the as yet unresolved true meaning of "authority" should at the least subsume the above meaning, although there are other instances where an object can have what appears additional authority. For example if you buy the last ticket for boarding a plane than that ticket gives you the authority to board but additionally it also prevents anyone else for purchasing any other tickets since it is the last ticket-- this prevention does seem to be an authority/right which mere possession of the that ticket gives the ticket holder. It has been suggested that these sorts of additional authorities should be called "negative authorities".

*** Object Capabilities are not the same as the Posix Capabilities. Object caps predate posix capabilities and were initially called just capabilities, but to avoid confusion with posix caps they have been renamed object caps.