Linux in-kernel keys support

[Damien Miller]

David Härdeman wrote:

> The disadvantage is that the kernel key storage doesnt support two things that
> the agent supports: signing challenges and asking for confirmation before
> allowing the use of a key. The former implies that secret keys are readable
> (by the user who added them) from the kernel which might not be wise from a
> security point-of-view.

Yes, that is the point of the agent - you can load your private keys in,
but not get them out.

> On the other hand, if someone was to break into your account, and thus was
> able to read the secret keys from the kernel....I imagine that he/she could
> already do similar things by reading the memory of the ssh-agent and/or using
> it to log into other machines...

We take steps to avoid attackers reading keys out: we prevent coredumps
and ptrace of the agent process. To prevent others accessing the agent
it checks that uid of the user making requests on it matches the one who
started it.

This doesn't help so much against a hostile root, but they could grovel
keys out of /dev/kmem anyway (this is where hardware tokens come in).

An attacker who breaks your account can still log in using the agent
that is there, but I guess that is a little better than being able to
take your keys away to continue their attacks at their leisure. To
reduce this risk further you can run with key restrictions, like
confirm-on-use ("ssh-add -c ..." - highly recommended).

> I hope that cleared things up a bit...now, is the idea somewhat sane or is it
> whack?

Well, unless the kernel gets challenge-signing capabilities, then you
would be sacrificing security because an who breaks your account can
read your private keys.

OTOH, if the kernel gets the ability to sign challenges then we could
treat it as a hardware token using the existing OpenSC code. Writing a
token interface to the kernel keystore would be a really cool project
for someone interested.

If you are frustrated by managing keys between lots of agents, then you
can ask it to puts its SSH_AUTH_SOCK in a well-known place using (e.g.)
"ssh-agent -a ~/.ssh/agent-sock"

-d