linux-kernel - Re: [PATCH] KEYS: Add ECDH support

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]

Message-ID: <fbc4bb78b39ab5b088b215cf854487022e59bbb4.camel@HansenPartnership.com>
Date: Sun, 31 Mar 2024 09:01:22 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Zhang Yiqun <zhangyiqun@...tium.com.cn>, dhowells@...hat.com, 
	jarkko@...nel.org, corbet@....net, keyrings@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH] KEYS: Add ECDH support

On Sat, 2024-03-30 at 17:48 -0700, Eric Biggers wrote:
> On Sat, Mar 30, 2024 at 09:09:51AM -0400, James Bottomley wrote:
[...]
> > For instance there are people who use the kernel keyring to replace
> > ssh-agent and thus *reduce* the attack surface they have for
> > storing
> > ssh keys:
> > 
> > https://blog.cloudflare.com/the-linux-kernel-key-retention-service-and-why-you-should-use-it-in-your-next-application/
> > 
> > The same thing could be done with gpg keys or the gnome keyring.
> 
> First, that blog post never actually said that the "replace ssh-agent
> with kernel keyrings" idea was deployed.  It sounds like a proof of
> concept idea that someone thought was interesting and decided to blog
> about.  Upstream OpenSSH has no support for Linux keyrings.

The openssh community is incredibly resistant to out of house
innovation.  It has no support for engine or provider keys, for TPM
keys, or for that systemd start patch xz just exploited ...

>   It seems unlikely it would get added, especially given the OpenSSH
> developers' healthy skepticism of using broken Linux-isms.
> You're welcome to bring it up on openssh-unix-dev and get their buy-
> in first.

I also didn't say just openssh.  You picked the one you apparently know
hardly ever accepts anyone else's ideas.  I don't disagree that finding
implementors is reasonable ... I just wouldn't pick openssh as the
first upstream target.

> Second, as mentioned by the blog post, the kernel also does not
> support private keys in the default OpenSSH format.  That sort of
> thing is an example of the fundamental problem with trying to make
> the kernel support every cryptographic protocol and format in
> existence.  Userspace simply has much more flexibility to implement
> whatever it happens to need.

That's a complete red herring.  You don't need the kernel keyrings to
support every format, you just need a user space converter to import to
the kernel keyring format.  Every device or token that can replace key
handling has their own internal format and they all come with importers
that do conversion.

> Third, ssh-agent is already a separate process, and like any other
> process the kernel enforces isolation of its address space.  The
> potential loopholes are ptrace and coredumps, which ssh-agent already
> disables, except for ptrace by root which it can't do alone, but the
> system administrator can do that by setting the ptrace_scope sysctl
> to 3 or by using SELinux.

Well, a) this doesn't survive privilege escalation and b) I don't think
many people would buy into the notion that we should remove security
functions from the kernel and give them to userspace daemons because
it's safer.

James