Re: [RFC][PATCH 8/8] SLIM: documentation

[David Safford <safford@watson.ibm.com>]

On Thu, 2006-08-24 at 15:11 +0200, Pavel Machek wrote:
> Hmm.. you are the security expert here :-). But it still needs private
> key while accessing the net.. so even if it does read from
> ~/.ssh/private_key, first,  what stops mozilla from waiting for
> ssh to start talking on the network, and then read the key from ssh's
> memory?

I think the only good way to protect a private key is not to
let the application see it at all, either by pushing the signature
operation into a wrapper, or into the kernel key ring, or even better,
into a hardware token, such as a TPM. Secrecy is really hard. There
are classes of software covert channels which have been proven to
be undetectable, so if you let software (particularly a browser)
see your private key, it may well not be your key any more.

> Do you have examples where this security model stops an attack?
> 								Pavel

The main goal of this model is to stop some of the most common real 
attacks on client machines, in particular the downloading and execution
of malicious code, through a browser or email attachment. By making
the email and browser applications run in an untrusted level, we can
keep them from modifying user or system level files, and any files they
create are labeled untrusted so that even system level processes can't 
accidentally invoke them at a trusted level. Also, we can control what 
applications are allowed to install packages, so that only signed packages 
(which are initially labeled as untrusted, since they came in over the net), 
are promoted and installed by the guard (e.g. rpm).

In one demo I like to run, I deliberately download a trojaned game, and
run it both as a user and even as root/system. Since the game is labeled
untrusted, it is invoked untrusted regardless of who runs it.

dave