Capdesk was a demonstration and user interface mockup that demonstrates that a secure operating system could be user friendly. Polaris demonstrates that such a system can be mostly backwards compatible, that existing windows software can run on such a system, and for the most part neither the user nor the program will notice any difference.
We now know, pretty well, how to build an operating system that is largely immune to viruses, Trojans and spyware. “Capdesk” was a demo of the design principles for a secure desktop operating system. It has led to similar, though more realistic versions retrofitted to windows and Linux, and sandboxes based on the same concept.
The key design pattern is the use of a “powerbox” to unite permission and designation. Trusted software, the powerbox, stands in the user interface between the user and the less trusted software, and when the user commands the less trusted software to do something, he unknowingly grants it permission – and without that permission, the less trusted software should be unable to do that thing.
Following Ivan Krstić’s design we can use this software pattern to ensure:
When a package is installed, the install scrip will use one of a limited set of possible install patterns. For this design pattern to be useful, installable packages need to come with install scripts adapted for the secure system, scripts that tell the secure system’s installer what sort of a package is being installed. A typical install pattern for an editor would give it read access to a very limited set of files, and read write access only to files in a special directory for that package and user – the package’s configuration area. To access any arbitrary file the user wanted edited, the “open file” on any program menu would launch a powerbox – trusted software that enables the user to select a file. The standard file select dialog box would be provided by the file selection powerbox, which quietly grants the less trusted program access only to selected files – thus combining designation with permission.
Among the needed powerboxes are:
To describe the powerbox user interface pattern for yet a third time: The way Linux and Windows work at present is that most programs have the power to access most files and most resources. Most programs run with the full power of the user, and anything the user is permitted to do, they are permitted to do. They are only supposed to access the things you tell them to, but can do anything that you could do. With the powerbox user interface pattern, most programs are incapable of accessing most files and most resources unless you tell them to, prevented by the operating system from doing pretty much anything until commanded to do it.
To describe the concept of combining designation with permission again: No one bothers to manage permissions until disaster ensues, and if they have to manage permissions, it is seldom clear what they should do – or more likely what they should have done to avoid the disaster that has just happened. Therefore we have to attach permission to the coat tails of designation, otherwise there is no way permissions are going to be managed correctly. Fixed up versions of Linux such as Plash, unlike the usual sandboxing approaches, remove the need to specify detailed policy information for each application by leveraging the information that is already available about the application in the form of standard package dependencies and by making smart use of existing facilities like the “Open File” dialog to infer security information.
Plash, however, is limited in what it can do without extensive user management and understanding, because it is an add on for Linux, rather than its own Linux distribution with its own repository of properly wrapped packages. If the user has to think about security, it is not secure. Most installable packages need to come out of the repository pre wrapped, rather than each user himself having to wrap each package, for in practice the end user swiftly gets sick of having to wrap each package, no matter how easy we make it, and worse, starts automatically clicking through dialogs without paying attention, thus creating a worse security hole than the ones we are trying to close.
The powerbox pattern is that we leverage designation information to generate permission information, and the powerbox user interface pattern is that we hook the user interface to extract transient permission information from user choices. Programs running under Plash can access only those files outside the sandbox that the user has selected. That dramatically limits the damage a malicious program can do.
Because normal programs have very limited write privileges in such an operating system, a flaw in one program cannot give the attacker control over the entire machine, and is considerably less likely to give the attacker durable control over even that program. A flaw in the browser would give the attacker control over that browser page, but without the ability to write to arbitrary files on the disk, it is difficult to leverage that control into control of all open browser pages, and more difficult to leverage that control into control of the browser after the next browser restart.
These fixed up versions of Linux and windows are operating systems that are a fair approximation to a secure user friendly environment, a decent first stab at it, sufficient that we can see what the final version should look like: Polaris, Bitfrost and Plash. All of these have serious problems, largely of incompleteness, and of horrible kludges to retrofit uncooperative software designed for an OS where each app gets total power, but they are workable and effective.
Of these secure versions, “Bitfrost” was the most thoroughly thought through, shortly before the time that I write this, though the situation is changing too rapidly to easily track. This document is not intended to provide an up to date bibliography of the latest progress. Bitfrost, as envisaged, has the requirement that any software that is installed, has to be installed by its custom installer which provides a secure environment for that software – and only software that has been wrapped in a package suitable for installation on Bitfrost can be installed, which means that the implementer can patch software that needs patching, and give special privileges to software that needs special privileges, while doing extra diligence on such software. Most software needs no special privileges or modification, and is thus trivial to wrap, though we need better facilities to allow the end user to wrap stuff, and more kinds of powerbox. When last I looked there were only two real powerboxes, one for file menus and one for the command line interface, and the rest are more demos than finished products. Indeed, I did not look that hard. Perhaps they were all demos to some extent, but even if all the powerboxes were mere demos back then the design is sound. We now know how to build a malware proof operating system.
In addition to protecting against abuse of trust, such as the program that reads private information and supplies it to the attacker who sells it to whoever is interested, we also need to protect against undue resource consumption.
Install should automatically and necessarily be reversible, by simply deallocating whatever resources and and privileges have been allocated to the package. Consumption of background processing time, background memory, boot up time, and so forth, all need to tracked and billed to each installed package, and the resulting information made available to the user in easily intelligible form, so that the user can detect those packages that are hogs. No program should be able to bring the system to a grinding halt by sucking up all available CPU cycles, or all available memory, or all available disk space. It should be easy for the user to monitor and restrict resource consumption, both for particular processes, and for any particular installed package.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License