Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

[Alexander Bokovoy]

On Срд, 20 сак 2024, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Mar 08, 2024 at 08:37:19PM +0000, Aoife Moloney wrote:
> > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> >
> > This is a proposed Change for Fedora Linux.
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > We disable support of engines in OpenSSL
> >
> > == Owner ==
> > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > * Email: dbelyavs(a)redhat.com
> >
> > == Detailed Description ==
> > We are going to build OpenSSL without engine support. Engines are not
> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
> > The engine functionality we are aware of (PKCS#11, TPM) is either
> > covered by providers or will be covered soon.
> >
> > == Feedback ==
> >
> >
> > == Benefit to Fedora ==
> > We get rid of deprecated functionality and enforce using up-to-date
> > API. Engine support is deprecated in OpenSSL upstream, and after
> > provider migration caused some deficiencies with engine support. No
> > new features will be added to the engine. So we reduce the maintenance
> > burden and potentially attack surface.
>
> Hi,
>
> In systemd, we recently added support for engines in various tools:
> - systemd-{repart,measure} have --private-key-source=file|engine|provider
>   (this is C code).
> - ukify has --signing-engine.
>   This is Python code that calls sbsign or pesign to do parts of the
>   heavy lifting, and those binaries do not support providers. (At least
>   the docs are silent on this, please correct it they do.)
>
> So it seems we'd lose support for signing with keys stored on yubikeys
> and tpms and other fancy approaches if the proposed change goes through.
>
> --
>
> Also, what is the impact on:
> - kernel module signing in the build system 
scrips/sign-file.c would need to migrate from use of ENGINE_* API to
providers. This is trivial as the only use is to find pkcs11 engine and
then load a private key through it:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/s...
static EVP_PKEY *read_private_key(const char *private_key_name)
{
	EVP_PKEY *private_key;

	if (!strncmp(private_key_name, "pkcs11:", 7)) {
		ENGINE *e;

		ENGINE_load_builtin_engines();
		drain_openssl_errors();
		e = ENGINE_by_id("pkcs11");
		ERR(!e, "Load PKCS#11 ENGINE");
		if (ENGINE_init(e))
			drain_openssl_errors();
		else
			ERR(1, "ENGINE_init");
		if (key_pass)
			ERR(!ENGINE_ctrl_cmd_string(e, "PIN", key_pass, 0),
			    "Set PKCS#11 PIN");
		private_key = ENGINE_load_private_key(e, private_key_name,
						      NULL, NULL);
		ERR(!private_key, "%s", private_key_name);
	} else {
		BIO *b;

		b = BIO_new_file(private_key_name, "rb");
		ERR(!b, "%s", private_key_name);
		private_key = PEM_read_bio_PrivateKey(b, NULL, pem_pw_cb,
						      NULL);
		ERR(!private_key, "%s", private_key_name);
		BIO_free(b);
	}

	return private_key;
}

Dmitry, I think it is something your team needs to handle (submit
support for provider vs engine to Linux kernel upstream).

> - signing of shim, grub2, fwupd, and the kernel in the build system
> - mokutil 
mokutil does not use ENGINE_* APIs at all.



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland