On Jan 27, 2006, at 17:19, Trond Myklebust wrote:
On Fri, 2006-01-27 at 21:41 +0100, David Härdeman wrote:
For example, a backup daemon which wishes to store the backup on
another host using ssh. Usually this is solved by storing an
unencrypted key in the fs or by providing a connection to a ssh-
agent which has been preloaded with the proper key(s). Both are
quite inelegant solutions. With the in-kernel support, the daemon
can request the key using the request_key call, and (provided
proper scripts are written), the user who controls the relevant
key can supply it. This in turn means that the backup daemon can
sign using the key and read its public parts but not the private key.
...but why would you want such a daemon to live in the kernel in
the first place? A backup application might perhaps need some
kernel support in order to ensure filesystem consistency, but that
does not mean that moving the entire daemon into the kernel is a
good idea.
No, the point is not to put the backup daemon into the kernel, but to
provide a way for the backup daemon and my user process to
communicate DSA key details without completely giving the backup
daemon my key. I may not entirely trust the backup daemon not to get
compromised, but with support for the kernel keyring system,
compromising the backup daemon would only compromise the backed up
files, not the private keys and other secure data.
Cheers,
Kyle Moffett
--
I lost interest in "blade servers" when I found they didn't throw
knives at people who weren't supposed to be in your machine room.
-- Anthony de Boer
-
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]
