357 lines
15 KiB
HTML
357 lines
15 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en"><head>
|
||
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
||
<style>
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 2em;
|
||
}
|
||
p.center {text-align:center;}
|
||
}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>Safe Operating System</title>
|
||
</head><body>
|
||
|
||
<p><a href="./index.html"> To Home page</a> </p>
|
||
|
||
<h1>Safe Operating System</h1><p>
|
||
|
||
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. </p><p>
|
||
|
||
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
|
||
<a href="http://www.cl.cam.ac.uk/research/security/capsicum/">
|
||
sandboxes</a> based on the same concept. </p>
|
||
|
||
<ul>
|
||
<li>Resources, such as files and directories, should be
|
||
owned by packages, or package*user, not merely users,
|
||
so that one package cannot interfere with another package,
|
||
so that packages cannot run with the full authority
|
||
of the user, and so that a package cannot be furtively installed
|
||
(for to be installed, has to be allocated resources, such as
|
||
a directory for its executable files to live in)</li>
|
||
|
||
<li>The principle of least authority: Programs
|
||
should not run with the full authority of the user.
|
||
Your solitaire game does not need authority to read your
|
||
contact list and spam them in each other’s name, put a
|
||
plugin in your browser that will watch what websites you
|
||
login to, stash the information and sell it to
|
||
advertisers, monitor your bank logins, collect the
|
||
passwords and bank account numbers, sell the collected
|
||
information to the highest bidder, use all your disk
|
||
space to store child porn, spam the entire world offering
|
||
to sell the child porn on your computer in your name,
|
||
while forwarding any payments to Nigeria, and use any
|
||
remaining bandwidth to launch a distributed denial of
|
||
service attack against popular web sites.
|
||
|
||
</li><li>The powerbox user interface pattern, so that
|
||
instead of each program needing durable authority to do
|
||
anything the user might command it to do, it instead
|
||
receives ephemeral authority to do the particular thing
|
||
that the user has commanded it to do..
|
||
|
||
</li><li>Default deny: Instead of having a long, and ever
|
||
growing list of forbidden programs and trying to detect them
|
||
in an ever more tedious virus and malware scan, it should
|
||
only be easy to install programs signed by an authority that
|
||
the operating system writer or end user has chose to trust.
|
||
Installation of other programs should require resort to the
|
||
command line or some similar obstacles. There should be no
|
||
one click installs of unsigned software, and even when
|
||
installing signed software the user should see, as on the
|
||
Android operating system, a list of authorities the program
|
||
wants, and have to approve those authorities. </li> </ul><p>
|
||
|
||
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 <em>unable</em> to do that
|
||
thing. </p> <p>
|
||
|
||
Following Ivan Krstić’s design we can use this software
|
||
pattern to ensure:</p>
|
||
<ul>
|
||
<li>
|
||
|
||
No program that can be executed merely by viewing
|
||
email or browsing to a web page or reading a document
|
||
can have persistent effects, or indeed effects outside
|
||
that web page’s window and server, except by something
|
||
such as offering up a standard widget that end user can
|
||
click on to get a save file dialog, or offering up a
|
||
standard widget that the user can click on to spawn a
|
||
new window, because these standard widgets
|
||
enable the powerboxes that grant permissions.</li><li>
|
||
|
||
No package can be installed except by the end user
|
||
clicking on the standard install widget. </li><li>
|
||
|
||
No package can be installed except it comes from a
|
||
source that the end user or OS writer has chosen to
|
||
approve, or a source approved by an authority they have
|
||
chosen to approve. </li><li>
|
||
|
||
No package can be installed except through the
|
||
standard series of installation dialogs. </li><li>
|
||
|
||
Every package so installed gets a corresponding and
|
||
effective series of uninstall dialogs. No package
|
||
can rootkit itself, even if the user is root, because
|
||
it cannot edit operating system files, or indeed any
|
||
files outside its own package, unless the user
|
||
chooses to open such a file through its file open
|
||
dialog. Deallocating all resources granted to a package
|
||
will uninstall the package, because the package has no
|
||
means to insert its code outside those resources behind
|
||
the user’s back. </li><li>
|
||
|
||
If a package needs authority to do X once installed,
|
||
it will only get it if the installation dialogs depict
|
||
the package to the end user as one of a category of
|
||
packages that the designer of the standard installation
|
||
interface has decided needs authority to do X. Thus
|
||
for example a sound player needs access to /dev/dsp. It
|
||
does not need authority to read arbitrary directories,
|
||
delete files, and so forth, because when it opens the
|
||
file select box, it opens a powerbox, trusted software
|
||
that <em>does</em> have authority to do file stuff – on
|
||
the users command, rather than the sound player’s.
|
||
command. Similarly an indexing program will have very
|
||
broad authority to read files, but very limited authority
|
||
to write files or access the internet. There
|
||
will be a couple of dozen package types.</li><li>
|
||
|
||
If a package needs some combination of authorities that
|
||
the designer of the installation interface failed to
|
||
anticipate, then the user must initiate some complicated
|
||
process and type in the necessary options to create a
|
||
new category of installable package in preparation for
|
||
installation, rather than clicking OK after the
|
||
installation is under way. </li><li>
|
||
|
||
A package can only be upgraded if the upgrade package is
|
||
of the same category as the package to be upgraded and
|
||
thus has the same authorities, and the upgrade and
|
||
package to be upgraded carry digital signature evidence
|
||
that they originate from the same entity. </li><li>
|
||
|
||
Any package that if installed that might look confusingly
|
||
like another installed package will be flagged by the
|
||
install process, which will ask the user for a petname
|
||
to differentiate the packages. </li><li>
|
||
|
||
Each package gets its own <a href="safe_operating_system_config_data.html"> exclusive
|
||
area to store configuration information</a>, and data in
|
||
this area can only be changed in ways that the package
|
||
is willing to accept, short of the package being
|
||
uninstalled altogether.</li><li>
|
||
|
||
The operating system provides protocol negotiation to
|
||
minimize <a href="bitrot_and_protocol_negotiation.html">bitrot</a>.
|
||
</li>
|
||
</ul>
|
||
<p>
|
||
|
||
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
|
||
<em>only</em> to selected files – thus combining
|
||
designation with permission. </p>
|
||
<p>
|
||
|
||
Among the needed powerboxes are:</p>
|
||
<ul>
|
||
<li>
|
||
|
||
The file select dialog.</li><li>
|
||
|
||
The command line, which should not only tell programs what
|
||
files to access but also enable them to access those files
|
||
and only those files.</li><li>
|
||
|
||
The project file powerbox, which manipulates files that
|
||
are lists of files and lists of tasks for other programs
|
||
to do with those files, and enables those
|
||
programs to work on those files.</li><li>
|
||
|
||
The account configuration powerbox, which enables programs
|
||
such as one’s email client or one’s newsreader that access
|
||
particular hosts through an account on that host, hosts
|
||
that seldom change, to access those particular hosts using
|
||
those particular protocols. It should be possible for
|
||
the end user to launch this powerbox from within the
|
||
browser from the host’s web page with the configuration
|
||
details filled in, if the host cooperates and is aware of
|
||
the protocol for doing so.</li>
|
||
</ul>
|
||
<p>
|
||
|
||
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
|
||
<em>supposed</em> 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
|
||
<em>incapable</em> 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. </p>
|
||
<p>
|
||
|
||
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. </p>
|
||
<p>
|
||
|
||
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. </p>
|
||
<p>
|
||
|
||
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. </p>
|
||
<p>
|
||
|
||
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.
|
||
</p>
|
||
<p>
|
||
|
||
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. </p>
|
||
<p>
|
||
|
||
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 <em>only</em> 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. </p>
|
||
<p>
|
||
|
||
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. </p>
|
||
<p>
|
||
|
||
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. </p>
|
||
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
||
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
||
Commons Attribution-Share Alike 3.0 License</a></p>
|
||
|
||
</body></html> |