ssl-cert should (re)generate /etc/ssl/private/ssl-cert-snakeoil.key on first boot
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| casper (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
| Mantic |
Confirmed
|
Undecided
|
Unassigned | ||
| livecd-rootfs (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
| Mantic |
Fix Released
|
Undecided
|
Unassigned | ||
| ssl-cert (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
| Mantic |
Fix Released
|
High
|
Unassigned | ||
Bug Description
casper has a script, 22sslcert, whose purpose is to regenerate the default snakeoil certificate on boot of a live system. This was done to fix bug #337723, which reported that the snakeoil SSL certificate (and private key!) was the same on all live systems booted from the same image.
The rationale given in the bug for wanting a different key on each system is not entirely correct; it claims the certificate is used for "browsing over https", which is not so. And the ssl-cert package is included in the live images for all desktop flavors because it's a dependency of cups-daemon, which is in desktop-common; but cups-daemon does not use this keypair, instead generating its own on demand (since 2017). However, there are other packages that are not part of the default desktop environment and may be installed by the user afterwards that reference this key (postfix is one), so we shouldn't have the same "private" key on all installed systems.
The casper script fixed this for the live environment, and ubiquity also includes code to wipe it from the target system. But subiquity-based installs don't do this - because they populate the target system from the read-only squashfs, not from the live environment - and I think OEM installs also fail to do this because the ubiquity code in question isn't part of oem-config, so the "private" key may be unique to the preinstalled system but will also definitely have been exposed to the OEM in the factory.
An option for implementing this consistently might be to have the ssl-cert package ship a systemd unit with ConditionFirstB
This would then let us drop the code in casper as redundant and instead keep the logic local to the responsible package.
Related branches
- Michael Hudson-Doyle: Approve
-
Diff: 43 lines (+17/-0)2 files modifieddebian/changelog (+5/-0)
live-build/auto/config (+12/-0)
- Michael Hudson-Doyle (community): Needs Information
- Nick Rosbrook (community): Approve
- Ubuntu Server: Pending requested
- Dan Bungert: Pending requested
-
Diff: 60 lines (+23/-1)4 files modifieddebian/changelog (+9/-0)
debian/control (+2/-1)
debian/rules (+1/-0)
debian/ssl-cert.service (+11/-0)
| description: | updated |
| Changed in ssl-cert (Ubuntu): | |
| importance: | Undecided → High |
| status: | New → Triaged |
| milestone: | none → ubuntu-23.10 |
| tags: | added: foundations-todo |
| Steve Langasek (vorlon) wrote | #1 |
| Steve Langasek (vorlon) wrote | #2 |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in livecd-rootfs (Ubuntu Mantic): | |
| status: | New → Fix Released |
| Launchpad Janitor (janitor) wrote | #4 |
| Changed in ssl-cert (Ubuntu Mantic): | |
| status: | Triaged → Fix Released |
| Launchpad Janitor (janitor) wrote | #5 |
| Changed in casper (Ubuntu): | |
| status: | New → Confirmed |
Note that the casper script in question is also buggy if the user is booting with persistence enabled, as the ssl certificate will be regenerated on every boot.
In contrast, /etc/machine-id is an empty file in all of our live images (.... but I can't figure out HOW because I see no code for this in livecd-rootfs!), so a first-boot systemd unit would run each time a live image is booted without persistence, but if using persistence /etc/machine-id would be populated in the persistence layer the first time and the ssl cert would not subsequently be regenerated.
Also, as a side effect, fixing this properly will cause the desktop live images to boot a smidge faster because they're not running an entropy-dependent single-threaded operation in the initramfs and can instead run it a little bit more parallelized from the rootfs (or maybe it will be faster because there's more entropy available at that point)