On Sat, Jan 28, 2006 at 10:20:29PM -0500, Trond Myklebust wrote:
On Sat, 2006-01-28 at 17:57 +0100, David Härdeman wrote:
What about the first paragraph of what I wrote? You are going to want to
keep often-used keys around somehow, proxy certificates is not a
solution for your own use of your personal keys and with the exception
of hardware solutions such as smart cards, the keys will be safer in the
kernel than in a user-space daemon...
I don't get this explanation at all.
Why would you want to use proxy certificates for you own use? Use your
own certificate for your own processes, and issue one or more proxy
certificates to any daemon that you want to authorise to do some limited
task.
I meant that you can't use proxy certs for your own use, so you still need
to store your own cert/key somehow...and I still believe that the kernel
keyring is the best place...
...and what does this statement about "keys being safer in the kernel"
mean?
swap-out to disk, ptrace, coredump all become non-issues. And in
combination with some other security features (such as disallowing
modules, read/write of /dev/mem + /dev/kmem, limited permissions via
SELinux, etc), it becomes pretty hard for the attacker to get your
private key even if he/she manages to get access to the root account.
Further, the mpi and dsa code can also be used for supporting signed
modules and binaries...the "store dsa-keys in kernel" part adds 376
lines of code (counted with wc so comments and includes etc are also
counted)...
Signed modules sounds like a better motivation, but is a full dsa
implementation in the kernel really necessary to achieve this?
How would you do it otherwise?
Re,
David
-
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]