cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
deac6e35d1
wallet/docs/safe_operating_system.html
reaction.la 3c3a22578d
docs build still broken
2023-08-26 09:38:32 +10:00

358 lines
15 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!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.&nbsp; “Capdesk” was a demo of the design
principles for a secure desktop operating system.&nbsp; 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.&nbsp;
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.&nbsp; 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.&nbsp; </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.&nbsp; </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.&nbsp; </li><li>
No package can be installed except through the
standard series of installation dialogs.&nbsp; </li><li>
Every package so installed gets a corresponding and
effective series of uninstall dialogs.&nbsp; 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.&nbsp; 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.&nbsp; </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.&nbsp; 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.&nbsp; 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.&nbsp; </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.&nbsp; </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.&nbsp; </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>.&nbsp;
</li>
</ul>
<p>
When a package is installed, the install scrip will use
one of a limited set of possible install patterns.&nbsp; 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.&nbsp; 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.&nbsp;
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.&nbsp; 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.&nbsp; </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.&nbsp; 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.&nbsp; Most programs run with the full
power of the user, and anything the user is permitted to
do, they are permitted to do.&nbsp; They are only
<em>supposed</em> to access the things you tell them to,
but can do anything that you could do.&nbsp; 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.&nbsp; </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.&nbsp; Therefore we have to
attach permission to the coat tails of designation,
otherwise there is no way permissions are going to be
managed correctly.&nbsp; 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.&nbsp; </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.&nbsp; If the user has to think about security, it
is not secure.&nbsp; 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.&nbsp; </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.&nbsp; Programs running under Plash can access
only those files outside the sandbox that the user has
selected.&nbsp; That dramatically limits the damage a
malicious program can do.&nbsp; </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.&nbsp; 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.&nbsp;
</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.&nbsp; 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.&nbsp; </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.&nbsp; 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.&nbsp; 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.&nbsp; Indeed, I did not look that hard.&nbsp;
Perhaps they were all demos to some extent, but even if
all the powerboxes were mere demos back then the design is
sound.&nbsp; We now know how to build a malware proof
operating system.&nbsp; </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.&nbsp; </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.&nbsp; 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.&nbsp; It should be easy for the user
to monitor and restrict resource consumption, both for
particular processes, and for any particular installed
package.&nbsp; </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>
Reference in New Issue View Git Blame Copy Permalink