Ubuntu Developing "crypto-config" For System-Wide Cryptography Configuration

[adrien-n]

The catch is that most things I might want to secure these days run in containers... where such system-wide configuration is irrelevant. And conversely, anything not in a container is probably something I'm happy to trust to OS-shipped defaults.

(Again, author here)

Whether we'd want this system-wide configuration to apply to containers is an open question at the moment. Indeed, containers are used for separation but you might also expect system-wide configuration to apply inside containers. I'm not sure there is a one-size-fits-all answer. In any case, I don't see a technical issue.
Configuration is done with profiles and if you're using the same distribution on the host and in the containers, the profiles will be the same, so that the only data you need to pass to the containers is the profile name you want. Moreover, profile switching is merely a symlink and you can do that in your image recipes.

There could be smarter algorithms for profile choice forwarding: the "modern" profile on Ubuntu 24.04 and 18.04 wouldn't mean the same thing. It's also possible that profile could receive updates over time to adapt with landscape changes, in which case, the meanings could be fairly close across versions. Anyway, I think it's probably too early to settle on something and fortunately, we don't have to decide today.

Lastly, I wanted to mention that goes together with an effort to ensure that these choices are actually respected by all the software in the distribution. Seemingly innocuous features or choices are often in the way because if you merely change a library's default but an application has its own default configuration, your changes will be overwritten by the application. Sometimes, the application's default also go without updates during many many years and what was advanced becomes deprecated.
The situation is actually quite messy across the many thousands of free software libraries and applications; there is a lot of work to make everything consistent and without surprises.

[egorfine]

the entirety of Ubuntu including the kernel is not only atomic but snapped.

Is this sarcasm or are there plan to make ubuntu... like this?

I'm genuinely asking because it's hard to tell these days. Some things that were once thought to be absurd are not part of core systemd.

[Delgarde]

It's system-wide cryptographic options (which key/key exchange/hmac/whatever algorithms are enabled/disabled, key sizes, etc). The issue this software tries to help with is "there are at least three crypto libraries[1] in very widespread use across our packages and it's a PITA to configure them all". It's not a "one private key to rule them all" situation.

The catch is that most things I might want to secure these days run in containers... where such system-wide configuration is irrelevant. And conversely, anything not in a container is probably something I'm happy to trust to OS-shipped defaults.

[sarmad]

Although I’m sure it’s not exclusive to, this config could be getting itself wired up for the day that the entirety of Ubuntu including the kernel is not only atomic but snapped.

Do you know what the status of that is? I thought Ubuntu Core Desktop was aiming for a release by 24.04.

[NotMine999]

The only problem is its python dependency.

What? NO RUST dependency?

Well that surely can't be State Of The Art coding, right? Better investigate Red Hat/Fedora for using child labor.

[docontra]

The only system-wide cryptography setup should be for transparently secured system to system communication, or? But even for that you would want to have a specific system user owning the private keys to enable that. If you tie crypto to a system do you then need to restart the system to rotate keys? If not, is it then considered system-wide?
What is the use case(s) for system-wide cryptography?

It's system-wide cryptographic options (which key/key exchange/hmac/whatever algorithms are enabled/disabled, key sizes, etc). The issue this software tries to help with is "there are at least three crypto libraries[1] in very widespread use across our packages and it's a PITA to configure them all". It's not a "one private key to rule them all" situation.

[1]: openssl, gnutls, nss (Mozilla), among many, many others (libressl, boringssl, mbedssl, wolfssl, the list goes on and on)

[adrien-n]

Author here.

What is the use case(s) for system-wide cryptography?

The point of a Linux distribution is to have a consistent set of software where everything integrates and plays well together. The configuration of cryptography is something where distributions typically fall short today.

I have a table somewhere which shows how 6 or 7 widely-used packages taken at random all have different TLS configurations: ciphers, elliptic curves, key sizes, ...

Trying to unify everything makes some things obvious. One example is postgresql which uses P-256 and for compatibility and future-proofness, one would like to also handle e.g. P-384. Unfortunately the code is not appropriate for several curves. Therefore it's not possible to have a nice upgrade path where you would support P-256 but also a stronger curve and once the migration to the stronger curve is far enough, stop offering P-256. This shows how not having a unified configuration can hurt.

Now, do the same, but times 1000 packages.

As for keys, this is not a topic for crypto-config.

Finally, a word about rebooting: I'd like to avoid requiring that for new configurations to take effect and have a detection like with needrestart in order to offer rebooting the relevant services only. That's a topic for later however.

[mortn]

The only system-wide cryptography setup should be for transparently secured system to system communication, or? But even for that you would want to have a specific system user owning the private keys to enable that. If you tie crypto to a system do you then need to restart the system to rotate keys? If not, is it then considered system-wide?
What is the use case(s) for system-wide cryptography?

[Jumbotron]

Although I’m sure it’s not exclusive to, this config could be getting itself wired up for the day that the entirety of Ubuntu including the kernel is not only atomic but snapped.

[Britoid]

Red Hat/Fedora already has system wide default crypto policies via crypto-policies. https://gitlab.com/redhat-crypto/fedora-crypto-policies

Its very handy.

The only problem is its python dependency.