For 19.10, we should have no problem getting this in on time. However, we should seriously consider whether or not we want to point release 19.04 to get this in.

@wxl Thoughts?

@tsimonq2 We can still patch cala in older releases where Cala was present with the Security Team so if there's a respin in any other ISOs it gets included. For 19.10 it SHOULD land. But for the *repos* getting a fix in for older cala is still a prudent idea.

While we're at it, we might as well just do 3.2.10, the latest Calamares.

I doubt there will be any other 19.04 respins, so we'd have to do it by ourselves.

@tsimonq2 @teward @wxl

I was testing this in a qemu-vm with the latest calamares build from https://launchpad.net/~lubuntu-ci/+archive/ubuntu/unstable-ci/+packages

Unfortunately it did not work. Looking at https://github.com/calamares/calamares/issues/1191 confirms that it is very likely a problem on our site. I am not sure, if it is a Lubuntu configuration issue or if it is a problem with mkinitramfs:

head /usr/sbin/mkinitramfs 
#!/bin/sh

umask 0022  <==============================================================
export PATH='/usr/bin:/sbin:/bin'

# Defaults
keep="n"
CONFDIR="/etc/initramfs-tools"
verbose="n"
# Will be updated by busybox's conf hook, if present

Today I redid the test with the actual (and 3.2.11 tagged) version of Calamares from https://launchpad.net/~lubuntu-ci/+archive/ubuntu/unstable-ci-proposed/+build/17227975

There were other changes in Calamares, and now the initrd.img in /boot has permission 600:

# Old
stat -c "%a %n" /boot/initrd.img-5.0.0-17-generic
644 /boot/initrd.img-5.0.0-17-generic
# From test today
stat -c "%a %n" /boot/initrd.img-5.0.0-17-generic
600 /boot/initrd.img-5.0.0-17-generic

unmkinitramfs fails now as expected.

The new Calamares has landed for Eoan (thanks @wxl). I have tested a FDE install and it clears up the CVE issues and works properly. More testing is warranted however.

@teward @apt-ghetto @Tj you all strike me as having a great degree of familiarity with this issue and the systems involved. I would love to know that you feel like everything is a-OK.

19.10 daily [2019-07-18] with -proposed calamares 3.2.11 installed, install using 'manual-partitioning' into partition (no encryption) flawless (default american english unchanged on first language choice)
19.10 daily [2019-07-18] with -proposed calamares 3.2.11 installed, install using 'replace-partition' into partition (no encryption) flawless (switched to british-english on first language choice)
19.10 daily [2019-07-18] with -proposed calamares 3.2.11 installed, install using 'replace-partition' into partition (encryption), british-english chosen first language choice, prior to booting this I rebooted into live & looked at hdd, luks partition where installed should be; I tried wrong passwords & couldn't access. I booted hdd with wrong passwords, unable to get in, final boot using correct password & was in; all looks good.

^ the above were done on dell optiplex 780 (BIOS)

I have tested it on a new vm as follows:

1. Boot live-system from iso
2. Open terminal
3. sudo apt update
4. sudo apt install calamares
5. Install the system on an encrypted device
6. Reboot into new installed system
7. Open terminal and test it with

sha512sum /crypto_keyfile.bin
sudo sha512sum /crypto_keyfile.bin

mkdir /tmp/init
unmkinitramfs /boot/initrd.img-5.0.0-20-generic /tmp/init
sudo unmkinitramfs /boot/initrd.img-5.0.0-20-generic /tmp/init

cd /tmp/init/main
sha512sum crypto_keyfile.bin
sudo sha512sum crypto_keyfile.bin

As expected, you need elevated privileges to access the key file.

I think, we should publish a blog post and explain it to the users, providing a solution for existing installations, which are prone to the vulnerability.

cd /etc/initramfs-tools/conf.d
echo "UMASK=0077" | sudo tee -a safe-initramfs.conf
sudo chmod 0600 safe-initramfs.conf
sudo update-initramfs -u -k all

Test it with the same procedure described above on a vulnerable system.

Great test case.

Regarding the fix for existing installations, I've got a crazy idea since we can't re-spin the ISO. How about we do an SRU on lubuntu-default-settings that has a post-inst script that checks for the fix and if it doesn't exists, applies it? We could put a file somewhere that records whether or not the script has run (probably file exists=script has not run) and the first part of the script checks for the existence of that file.

/etc/initramfs-tools/initramfs.conf UMASK=0077 is the correct fix for the user-reading-initrd.img issue.

This is what cryptsetup-initramfs requires when embedding a key-file in the initramfs.. See section 12 (line 234) "Storing keyfiles directly in the initrd"

https://git.launchpad.net/ubuntu/+source/cryptsetup/tree/debian/README.initramfs?h=ubuntu/disco

Created upstream bug to include UMASK in initramfs.conf and not in a separate configuration.

@apt-ghetto I'd recommend modifying the Calamares bug because it is partially incorrect.

Placing per-application over-rides in the ./conf.d/ directory is, as with many other system services, the recommended and preferred way for applications to add their own modifications to another package's configuration without editing that package's primary configuration file (in this case initramfs.conf).

This prevents problems when a package upgrades and the installed package-config file no longer matches that shipped and therefore presents the user with the choice to keep, replace, or examine the differences - often times the user will have no idea of what the correct choice should be especially when changes to the package-config conflict with the local changes.

However it might still make sense to conditionally apply the UMASK to /boot/ only when using encryption although I'd prefer a system where only UID 0 can read the files in /boot/ regardless of encryption - it's one more useful level of blocking casual attempts by malicious processes from gaining and exploting useful local information. That said, there's still much that can be learned from the entire /etc/ hierarchy as well as /proc/ and /sys/ (/sys/module/*/parameters in particular).

@Tj Thank you. I have changed the issue now.

So, I guess, you recommend also to create a SRU for 19.04 to add this configuration if [ -f /crypto_keyfile.bin ]?

Another thing: What happens if /etc/initramfs-tools/conf.d/A.conf defines UMASK=0077 and /etc/initramfs-tools/conf.d/B.conf defines e.g. UMASK=0007?

@apt-ghetto As with all ./conf.d/ parsing is in lexical order and in well-behaved packages uses the C locale rather than a regional locale to assure that the evaluation order is predictable.

This is why in other packages these conf-file fragments are usually prefixed with numbers because numeric ordering is identical in almost all locales.

Bump on this; would someone like to take care of writing a postinst script for lubuntu-default-settings and SRUing into 19.04?

Maybe we should make a task for that?

What, specifically, is a postinst script intended to deal with? The unconditional use of UMASK=0077 and removing it? Applying it if not already used?

As I said earlier this is actually a security gain regardless of LUKS usage and - if the suggestion is to have Lubuntu systems that can have either - could potentially make some issues harder to diagnose for operators and support agents ( although I struggle to think of any - but unexpected variations are always unwelcome! )

It would be helpful if we had an objective of what the script was to accomplish. If we just want to apply what @apt-ghetto suggested as a workaround:

cd /etc/initramfs-tools/conf.d
echo "UMASK=0077" | sudo tee -a safe-initramfs.conf
sudo chmod 0600 safe-initramfs.conf
sudo update-initramfs -u -k all

We could probably do that relatively easy in a Bash script.
Something like this:

#!/bin/bash
safeinit="/etc/initramfs-tools/conf.d/safe-initramfs.conf"
if [ -e "$safeinit" ]; then
	echo "$safeinit found exiting"
else
	echo "running initrd permission fix"
	echo "UMASK=0077" > $safeinit
	echo `chmod 0600 $safeinit`
	echo "run update initramfs"
	echo `update-initramfs -u -k all`
fi

Is that enough? Should we apply it to encrypted vs non-encrypted? How do we execute that with lubuntu-default-settings?
Sorry, I feel like I have more questions than answers on this.

It would be done via a postinst script.

Is this the way we want to go?

If there is no "platform expectation" from Ubuntu, I am in favour of always including UMASK=0077.

Shouldn't we inform the users and explain, how to fix it? Every installation from a 18.10/19.04 ISO is still vulnerable and will remain vulnerable for the next weeks, months, years.