Application code for Mac’s and Wintel systems runs with infinite authority. That was written about 1999. Now in 2004 this is no longer so. Both limit authority somewhat like Unix does. Application installers, still require near infinite authority however.) There is an unstated assumption, variously understood by users, that all application code can do anything including destroying all of the data on the machine. (Now in 2004 it can delete all the user’s work products, but not the system files.)

Unix, having been originally designed for more than one user, as in timesharing, propagated from earlier systems, the idea that each user should be able to view his access to the machine as private from other users — each user within his own realm. One user could neither see nor interfere with another’s use of the machine. The goals of Unix and its immediate predecessors was to provide the user with the convenience of having his own machine. Each user was confined to his realm, and safe there from travails in other realms. Unix and its ilk, did one more thing — it provided tools such as compilers and loaders to its users, for they might not have the knowledge or means to install the tools themselves. Furthermore with centrally provided tools, disk space was saved, but it was then necessary to protect those shared tools from acts in any realm, lest one realm impact another.

Those who built early timesharing systems, were programmers and built the systems for programmers and their professional colleagues. The programs running within the system were extensions of the users and did whatever the programmer-user desired. It was the late 70’s before most in the profession began to try to distinguish between user and programmer. Here is a short cultural history of early computer practice.

These designs implicitly assume that application code does just what the user wants it to do. Any other behavior is deemed a bug and the remedy is to fix the bug. There is no thought that the programmer who is in a position to fix the bug may have different interests than the user who suffers from the bug. Indeed the programmer and user may, unbeknownst to the user, have incompatible interests. The Trojan horse is the primary example of this.

The Mac or Wintel system has just one realm per machine. As of 2007 both allow several. Within a realm the application program runs with all of the authority of the user. Not even the tools or kernel are safe. As of 2007 there appears to be a policy of protecting the kernel and other system files. There remain holes. This makes the job of viruses and Trojan horses easy.

Two developments have recently made this issue even more critical, especially in combination:

That macro style code is portable across platforms exacerbates the security problem.

If applications are to run with authority limited to their legitimate requirements then the user would seem to have the added job of telling the computing platform what that authority is. The present note is to argue that such user effort usually displaces other work required in conventional systems, and when the work is indeed additional, it addresses basic user needs that conventional systems do not address.

In Unix, MacOS and Windows 95 the user must select what instance of a document (some sort of work product) is to occupy the attention of the application and user. In Unix the user selects the instance by providing to the application, some sort of forgeable name for the instance. The application uses its authority to access any of the user’s files by name, and accesses the one named by the user. A malicious application may access other unselected instances as well. In a capability system the user and system would provide to the application an unforgeable name (a capability) to the instance. The application would lack authority to access any other file. There seems to be no extra work here for the user or the application.

Communication software is notorious for stepping on the work product of other installers. This is ranted upon at length here where I claim that the authority required by the installed application is likely to be critical to other vital system functions. The user knows that there is a modem connected to his computer and it is no conceptual burden on the user to grant the modem to the application. Many times I have had to reboot my Mac because some forgotten program still had hold of the modem. I could neither find out what program it was, nor regain the use of the modem short of rebooting the machine.

My Address Book

I have recently been reluctant to switch to Apple’s e-mail client as it wants to use Apple’s Address Book for its intended purpose. Having heard of several abuses by malware of address books, I feel more comfortable with the obscurity of keeping my e-mail address list in the proprietary format used by an older commercial mail client. I feel that I know what uses those addresses are put to now. The address book is a public resource within my machine and many Java or JavaScript programs from unknown sources have first class access to my mail list. Programs running under the aegis of the browser, may indeed lack authority to my address book but where may I, an end user, be assured of this? Where indeed may I, even as a programmer, be assured of this? As a programmer I can read very thick manuals and note the lack of such facilities, but then perhaps I have not read far enough, or perhaps I have not read the proprietary manuals available only to developers who have signed NDAs. I would even be satisfied with a bald claim on the web site for the browser that there was no such access.

Even with plausible benign security policies of browsers I am left to the mercy of the hundred or so “applications” which make my PC useful, not to mention the viruses.

In a personal computer built on capability patterns there would be capabilities to address books held by just those programs that I trust to use those addresses as I wish. Some of these capabilities would alert me upon access to the lists while other capabilities would access the list silently. Some would enable adding names to the list and others would only allow reading. Some would allow reading only that subset having to do with work. Alternatively I would have separate address books for separate parts of my life. Applications with a capability to one book would be oblivious to the existence of others.

The Realm of the Principal is Obsolete

In summary the current dominant system architecture has changed little since the 60’s when the vision was of a programmer alone with his machine. Meanwhile the user of the machine has come to depend on large numbers of programs only a few of which he is aware of, none of the authors of which he has met, and not all of which have legitimate reason to be inside his machine. The user’s realm is now inhabited with programs by those with interests diverging in unknown ways from his own. The realm is obsolete as a protection boundary.

Epilog

There are protection mechanisms in Unix beyond those alluded to above. There are access control lists which discriminate more delicately who can do what to what things. This still buys into the idea that the bad guy can be defined by which user name denotes the villain. The villain probably has no user name! There has been a long running effort to introduce something called “capabilities” into the Posix standard. These are not capabilities in the sense of the computer science literature, nor in my sense. They do help to compartmentalize the infinite authority that now goes with root. They slice functionality into smaller hunks, but they do not subdivide realms. They do not address any of the points made here.

CapDesk illustrates a user interface that is compatible with solving this problem.

Cloud

IP connections are enough different to warrant discussion here. They are important in their own right and the pattern goes beyond communications.

Several well known scams are based on the ease of sending out IP data grams. This is the essence of unconfined computation. I run only a few programs that need to access IP. I, as user, would be willing to explicitly grant such programs categorical access to IP. It is like installing a modem on an application instead of installing in on my computer. This need not be an obscure concept. Conversely I can ask which programs have access to IP. This can be made graphical and most users will quickly see the ramifications.