On Thu, 2006-08-31 at 01:46 +0200, Pavel Machek wrote:
> So... will I be able to set ~/.ssh/private_key to USER-SENSITIVE and
> still use ssh to log in to remove machines? Will trojans coming from
> network be able to read that file?
>
> I do not think see how that can work... because ssh accesses network,
> and needs to know my private_key.
> Pavel
In an earlier post, I briefly mentioned using restructuring or a TPM
for the ssh case, but I didn't explain it well at all. I'll try to
do better:
You are absolutely correct that with the existing ssh implementation,
simply labeling an ssh private key as USER-SENSITIVE would be safe,
but would prevent ssh from writing to the PUBLIC network, which would
cause it to fail.
You could then make the ssh executable a secrecy guard, so that it
could read the private keys, and still write to the PUBLIC network,
but then, if the ssh process is compromised, the keys could be
leaked. This is still much better than discretionary access control,
as it prevents all other programs which are not explicitly labeled
as a secrecy guard from giving the keys away, but by making ssh a guard,
you are explicitly allowing it to access sensitive data and still
talk on a public connection. This is the inherent behavior of any
mandatory access control system; you label things and then either
allow access, or not.
One approach is then to minimize the amount of code you have to trust,
by restructuring the application. In the case of ssh, you could
separate out the code that uses the private key to do the actual
public key decryption into a small separate program, which has
to be trusted, and keep the rest of ssh, which handles the bulk
of the untrusted data, in a large untrusted program. Postfix
(www.postfix.org) is an excellent example of restructuring a large
monolithic program like sendmail, into small isolated components,
for better security and robustness, and this application structuring
complements MAC systems by reducing the trust granularities.
A better approach is to not let _any_ software see the private key,
by using a hardware device, such as a TPM, to create the private key
in the first place, and to do the actual public key operation.
(http://sourceforge.net/projects/trousers/ has open source applications
and libraries for TPM based openssl and pkcs11 crypto.) Then, even if ssh
is compromised, it can't give the private key away.
The bottom line is that mandatory access control helps significantly by
preventing any other application from leaking the ssh keys, and by
forcing you to designate ssh as trusted not to leak the keys. But
once you designate ssh as trusted, then it is up to other security
techniques, such as structuring, and hardware to protect the keys
further.
dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
