linux-kernel - Re: [RFC][PATCH 8/8] SLIM: documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Aug 2006 14:00:54 -0400
From:	David Safford <safford@...son.ibm.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Serge E Hallyn <sergeh@...ibm.com>, Mimi Zohar <zohar@...ibm.com>,
	David Safford <safford@...ibm.com>, kjhall@...ibm.com,
	linux-kernel <linux-kernel@...r.kernel.org>,
	LSM ML <linux-security-module@...r.kernel.org>,
	linux-security-module-owner@...r.kernel.org
Subject: Re: [RFC][PATCH 8/8] SLIM: documentation

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/