<?xml version='1.0' encoding='utf-8'?>
<html lang="en">
<h2>Security Model</h2>
<p>
This page describes Zero Install's security model.
</p>
<p>
I've noticed that if you describe a security model with digital signatures
and GPG keys, people start worrying about all kinds of unlikely theoretical
exploits. Whereas if you just stick software on the web with no security
what-so-ever, everyone seems completely happy to use it. But for those few
people who do care about security, this document explains how Zero Install
tries to improve the situation.
</p>
<toc level='h2'/>
<h2>Overview</h2>
<p>
No-one has the time to verify every line of code in every program they use.
Yet, we need to use these programs to process our data, and we must guard
against the possibility that the code we use is malicious. We need methods
to help ensure that we don't allow malicious code to run, to limit the damage
it can do if we do run it, and to discover and recover from compromises when
they do happen.
</p>
<p>
Some key points about Zero Install's security model:
</p>
<dl class='spaced'>
<dt>If one user downloads a malicious program, other users aren't affected</dt>
<dd>
In traditional systems, installing a program also puts files into shared directories like <b>/usr/bin</b>
and <b>/usr/lib</b> under short names. So if one user installs the Gimp from <b>http://evil.com</b> then it
might save the executable as <b>/usr/bin/gimp</b>. Another user might run this, thinking it was from
<a href='http://gimp.org'>http://gimp.org</a>. In a Zero Install system, users specify the full URI of
the program they want to run, and the system only shares the copy if they really are the same. The short-cuts
(e.g., that <b>"Run gimp"</b> means <b>"Run http://gimp.org/gimp"</b>) are
per-user, but the programs themselves are shared.
</dd>
<dt>Installation does not execute any downloaded code</dt>
<dd>
Most installation systems run code in the downloaded package as part of the installation process. Typically,
these scripts are run as root and can do anything they like to the machine. Zero Install merely fetches
files into the cache during installation; nothing downloaded is executed and files from different packages
cannot conflict (because they each go in their own directory).
</dd>
<dt>Digital signatures are always checked before software is run</dt>
<dd>
To protect against the possibility of attackers breaking into a web-server and replacing the real
software with modified versions, or redirecting network traffic to the real web-server to their own,
Zero Install only runs code that is signed by a GPG key you trust to provide software from that web-site. By default, it will automatically approve keys known to the key information server; this can be disabled from the preferences dialog.
</dd>
<dt>Security when <i>running</i> programs is your problem</dt>
<dd>
Zero Install goes to great lengths to get software on to your machine without
letting it do anything dangerous, but what happens next is up to you. On a
normal Linux system this still brings some benefits (e.g. users can share
programs without also sharing viruses), but the real advantages come when
you combine this with some sandboxing technology to restrict what programs can
do when running.
</dd>
</dl>
<h2>Demo!</h2>
<p>
For a demonstration of using sandboxing with Zero Install, see <a href='ebox.html'>ebox</a>.
</p>
<h2>Authorisation vs Privileges</h2>
<p>
It's also important to separate out two aspects of installation that are easily
confused: <i>who</i> is authorised to install software and <i>what privileges</i> the software
is given by the act of installing it. Here, "apt-get" is used as a short-hard
for "a typical traditional Linux package manager":
</p>
<table class='table'>
<tr><th></th><th colspan='2'>Who can install things</th></tr>
<tr><th>Privileges granted</th><th>Only root</th><th>Anyone</th></tr>
<tr><th>Full access</th><td>Default apt-get</td><td>apt-get with modified rules</td></tr>
<tr><th>No access</th><td>Zero Install with restrictions</td><td>Default Zero Install</td></tr>
</table>
<p>
A typical package manager only allows root (or an administrator) to install
software by default, and grants that software full access to the machine,
including access to all user accounts. You can change the rules to allow others to
install software (e.g. using PolicyKit or sudoers, you might allow anyone to upgrade a
package), but the software still gets complete access to the machine.
</p>
<p>
Zero Install allows anyone to install software by default, but gives the
software no access to the machine (since it doesn't run any of its code at
install time). You could configure Zero Install so that only root can install software,
but the software would still get no ability to do anything at install time.
</p>
<p>
The reason we allow anyone to install software by default is the principle of
<i>Do Not Prohibit What You Cannot Prevent</i> [citation needed]. On Linux, unprivileged
users can install software even without Zero Install, so trying to stop them makes life
harder for legitimate users but doesn't improve security.
</p>
<h2>Security and Usability</h2>
<p>
Some people think of security and usability as a trade-off, with systems being
either easy to use, or secure, but not both. But in fact, security is a
necessary part of usability. Some examples:
</p>
<ul>
<li><p>I used to program on a system which had no memory protection, allowing any
process to overwrite any other process's memory. Linux prevents programs from
doing this. This makes my life as a programmer easier, not harder, because
when a program crashes I know that the problem is in that program and not in
some other one.</p></li>
<li><p>Sometimes, I forget where I saved a file. But, I never need to search /usr
in case I accidentally saved my letter there; it can't be there, because my
word processor doesn't have permission to save there.</p></li>
<li><p>Windows users (so I hear) often find their computers are infected with spyware
and adware, which slows them down, causes crashes, and redirects them to
undesirable web sites. Such a system has poor usability.</p></li>
<li><p>An artist may find a useful image processing filter on the web. If all
this filter can do is read an input image and output a modified one then the
artist is more likely to try it (and produce better work). If image filters can
seriously damage the system then the artist may have to pass it over; the risk from
a malicious filter is too great.</p></li>
<li><p>Few programs are as easy to run in a restricted environment as the image
filter example above; an accounting package needs access to my accounts, for
example. Still, with good security we can evaluate lots of possible
programs and then only weigh up the risk for the one we choose. Without good
security we must evaluate fewer programs, and we are at risk from each one we
try.
</p></li>
</ul>
<p>
Good security is therefore vital to a usable system. A usable system must be
understandable and predictable; on a system where any action can have any
consequence this is not possible.
</p>
<p>
Consider traditional software installation on Linux or Windows. You download
some package and execute a script inside it. Imagine that I give you a package
in your favourite format (setup.exe, .deb, .rpm, source tarball, etc) and
ask you to install it. Assume that your system is functioning correctly; what
will happen as a result of installing this program?
</p>
<ul>
<li>Will a new item appear on your Start menu (or equivalent)?</li>
<li>Will some other program on your computer stop working as a result of a
installing this one?</li>
<li>Will a new service be added to your boot sequence?</li>
<li>Will your browser's saved passwords be posted to an IRC server and your
hard disk reformatted?</li>
</ul>
<p>
The answer, for all the formats listed above, is "I don't know". With Zero
Install, none of these things can happen without some extra action on your part.
</p>
<p>
Now, Zero Install is <i>not</i> a complete solution to these problems. In
particular, it does not stop programs from doing any of these things when
<i>run</i>. That problem is for some other project to solve (and there are
plenty of people working on this; see <a
href='http://plash.beasts.org/'>Plash</a> or <a
href='http://www.systrace.org/'>SysTrace</a> for example).
But Zero Install already brings benefits without the use of these programs
(the effects above which require root access will be blocked), and it is clearly a
necessary base on which such technologies can be built. Being able to run
software in a sandbox is of limited benefit if it requires full root access to
install it first!
</p>
<h2>Zero Install's trust model</h2>
<p>
Sandboxing is used to restrict what code can do. Linux and similar systems come
with a simple sandboxing system based on users. The system has a number of
users, and each user can run whatever software they please. Ideally, it is
not possible for malicious code executed by one user to damage the system or
threaten the security of any other user. However, the code can do anything that
the user running it is permitted to do (such as delete that user's
files, or log the user's keystrokes and send them to another computer).
</p>
<p>
A second approach is to ensure that only software written by trusted
individuals is run. This presents two problems: how do we come to trust
someone to provide reliable software, and how do we know that a particular
program really came from them?
</p>
<p>
The basis of Zero Install's model is the standard multi-user model used by
Linux. The principle is that the system's responsibility is to protect users
from each other, and to protect the system from the users. If one user (or
a program they run) can delete another user's files without permission, then
that is a problem with the system's security. However, the system is not
responsible for protecting users from themselves; it is up to users to take
appropriate measures to prevent the programs they run from damaging their
own files, for example.
</p>
<p>
Of course, the system may itself have bugs. Ideally, the system should be
upgraded when a problem is found (e.g. in the Linux kernel). However, if users
are using sandboxing to protect themselves from the programs they run then
this may provide an added layer of protection to the system, assuming the
users themselves are not malicious.
</p>
<p>
Users can protect themselves by using additional sandboxes within their
own sandboxed user account. A good example of this is
<a href="http://user-mode-linux.sourceforge.net/">User-Mode-Linux</a>, which
runs a new Linux system within a single user account of a main Linux system.
The user can use the sub-Linux's security features to restrict what
applications can do inside it, while the whole sub-Linux system is restricted
to the user's permissions within the main Linux system. More light-weight
sandboxes include running JavaScript in a web browser, or running Java
applications with Java's sandboxing turned on.
</p>
<p>
However, good per-user sandboxing is still more of a long-term goal for Linux
than a practical solution for many programs at the moment (but see
<a href='http://plash.beasts.org/'>Plash</a> for a good example of where
things are heading). Also, some programs really do need full access to the
user's files. For example, a file manager needs to be able to delete the user's
files, and an email client needs to be able to read the user's emails and send
new ones, so making sure that software is not malicious in the first place is
very important.
</p>
<p>
When deciding whether to trust a particular programmer, the user will have to
consult external sources. Distributions typically fill this role (recommending
certain programs only), and friends, magazines, etc, can provide this
information too.
</p>
<p>
A trusted programmer is identified by their GPG key's fingerprint. When the
user runs a program, Zero Install downloads the feed and checks that it
is signed by someone the user trusts. If not, the user is asked to confirm
that they trust the holder of the key to provide software to them:
</p>
<p style='text-align: center'>
<img width="477" height="463" src="confirm-tal-rox.png"
alt='You are asked to confirm each new key'/>
</p>
<p>
Once trusted, Zero Install will accept any feed from the same domain
signed by that key.
</p>
<p>
Zero Install updates feeds at the request of the user (clicking the
'Refresh' button), or automatically (monthly, by default) if the
user sets their freshness policy to request this. If a program is not
used, Zero Install does not check for updates to it.
</p>
<p>
Zero Install does not accept incoming network connections, so even if a malicious key
is trusted, the owner must still get the user to download a feed they
control.
</p>
<h2>Possible attacks</h2>
<p>
To run malicious software on a user's machine, an attacker could:
</p>
<ul>
<li>Publish the software on their own web-page, and convince users to run it, or</li>
<li>Cause their software to be run when the user tries to run some other program.</li>
</ul>
<p>
Guarding against the first requires educating users not to run untrusted software (this
applies whether using Zero Install or not), sandboxing any software that is run if possible,
and advising users that the software is unknown and/or known to be malicious.
Organisations may wish to keep their own internal database of programs approved
for use within the organisation, and to prevent users from installing programs
not on this list.
</p>
<p>
To perform the second attack, the attacker needs to replace a trusted feed
file on a server with a compromised version. However, the new file must be
signed, and the secret signing key should not be on the server. Therefore, the
attacker has two options:
</p>
<ul>
<li>Break into the developer's private machine, get their private GPG key,
install a keystroke logger, and get the GPG pass-phrase. Then break into the
web server and install a compromised signed feed.</li>
<li>Break into the webserver and install a feed signed with their own
key (a new key with a new fingerprint, but claiming to belong to the original
author), and trick users into accepting it.</li>
</ul>
<p>
The second option is probably easiest. Zero Install currently warns users if
they run software signed with an unknown GPG key (we maintain a default
database of known keys, but we do not have the resources to verify the owners
of the keys). Note that even if a key is in the known keys database, users
must still agree to trust that key. Again, organisations may wish to keep their
own white-list of allowed keys.
</p>
<p>
The first option can be made even harder if the developer has a second
(non-networked) machine with the GPG key, although not all developers will
have a spare machine for this purpose.
</p>
<h2>Conclusions</h2>
<p>
We have discussed the need for security and the differences between traditional
software installation systems and Zero Install. While installing software with
traditional systems can cause arbitrary changes to your system, Zero Install
does not run any of the downloaded code during installation; it merely unpacks
files to a new directory.
</p>
<p>
Securing the installation process is not the whole story; software should also be
<i>executed</i> in a restricted environment. Several other projects are
developing suitable sandboxes. Even without such extra programs, the default
security mechanisms built in to Linux provide improvements over traditional
installation.
</p>
<p>
Whether we have strong sandboxing or not, it is important to know where software
has come from and to only accept digitally signed software. Zero Install maintains
a list of trusted keys, and aids the user's decision of whether to trust a key
using its database of known keys. The default database provides only low security;
organisations may wish to provide their own database and perform real verification
checks on authors. Organisations may also wish to prevent users from installing
unapproved software at all.
</p>
<p>
An attacker wishing to install malicious software must either trick users into
trusting them, or steal a trusted developer's GPG key. This is considerably more
secure than most other distribution systems, many of which contain no security at
all.
</p>
</html>
