posted by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC



The basic security model used by Linux and similar systems is to have different users, each in their own security domain. Each user must trust the core system (e.g. the kernel, the login system, etc) but the system is protected from malicious acts by users, and users are protected from each other.

In this essay, I've talked about malicious users in several places, but it's important to realise that this includes otherwise-trustworthy people who are (accidentally) running malicious software, or whose account has become infected with a computer virus, or who have failed to choose a secure password, and so on. So even on a family computer, where the people all trust each other, there is benefit to containing an exploit in a single user's account.

Many Linux installation systems work by downloading a package and then executing a script within it with root access, and copying files into locations where they can affect the whole system. If you tell your computer to "upgrade all packages" each week, there may be several hundred people in the world who can execute any code they like on your machine, as root, within the next seven days!

For some packages, this is reasonable; you can't expect to keep your kernel up-to-date without trusting the kernel's packager. For others (desktop applications, for example) we might hope to limit them to destroying only the accounts of users who actually run them. Games, clipart, and documentation packages should ideally be unable to damage anything of value. This is the Principle of least privilege.

As well as malicious or compromised user accounts, we must also consider the effects of an insecure network, hostile web-sites, compromised servers, and even malicious software authors.

Klik is activated by the browser trying to resolve a URL starting with 'klik://'. Firefox displays a confirmation box to prevent malicious sites from starting an install without the user's consent, although the dialog does give the user the option to defeat this protection in future:

Firefox confirmation

Autopackage requires the user to download the package file and then run it from the file manager. Firefox extensions can only be installed from white-listed sites, and a count-down timer prevents users accidentally clicking on Install. Zero Install requires the user to drag the link from the web-browser to some kind of installer or launcher (e.g. onto a Start menu), and requires confirmation that the author's GPG key is trusted:

Key confirmation

Transport Layer Security (e.g. the https protocol) can protect against insecure networks and replay attacks. It allows the client to be sure that it is talking to the host it thinks it is, provided the remote host has a certificate signed by a trusted CA. However, TLS requires the private key to be available to the server providing the software; the server does not require any action from a human to make use of this key. This means that an attacker breaking into the server and modifying a program will go undetected.

An alternative approach is for the author of the software to sign it on their own computer and upload the signature to the server. This should be more secure, since the developer's signing machine is much less exposed to attackers (it may not even be on a network at all). It also allows mirrors to host the software, without the user having to trust the mirrors.

In fact, rather than signing the software itself, we may prefer to sign the XML file describing it. The XML file contains the digest of each version, as explained above, and the software can be verified from that. The advantage here is that the actual package file doesn't need to be modified. Also, the signature remains up-to-date, since the author re-signs the whole XML file on each new release (signing keys should be updated from time-to-time to use stronger algorithms and limit the effect of compromised keys).

The downside of these static signatures is that replay attacks are possible, where an attacker (or mirror) provides an old version of a program with known security flaws, but still correctly signed. To protect against this, Zero Install records the time-stamp on the signature and refuses to 'upgrade' to a version of the XML feed with an earlier signature. This warning should also make it obvious to those users who did get a more recent version that a break-in has occurred.

The signed XML file must also include the globally unique name of the program; it's no good trusting a correctly-signed version of 'shred' when you asked your computer to open the file with a text editor!

As always, users have the problem of deciding whether to trust a particular key in the first place. The hint in the screenshot above is from a simple (centralised) database supplied with Zero Install, and only says that the key is known, not trustworthy. A useful task for a QA team (or distribution) would be to add their signatures to approved versions of a program, or to provide their own database of trusted keys.

A final point is that we may want to give different levels of trust to different programs. If I am evaluating six accounting packages then I will probably want to give them all very limited access to my machine. Once I have chosen one, I may then give that single program more access.

Sun's Java Web Start is able to use the security mechanisms built into Java to run programs in a restricted environment. Other systems may use more general sandboxing tools, such as Plash.

Table of contents
  1. "Introduction, Use Cases, Traditional Distributions"
  2. "Naming, Conflicts"
  3. "Avoiding Conflicts, Dependencies"
  4. "Publishing Software, Sharing Installed Software"
  5. "Security"
  6. "Compiling, Converting Between Formats"
  7. "Summary"
e p (8)    76 Comment(s)

Technology White Papers

See More