Desktop installer is outdated

[Haug Bürger]

Am 09.05.20 um 02:02 schrieb Dimitri John Ledkov:
> On Sun, 3 May 2020 at 07:34, Haug Bürger <habu at posteo.de> wrote:
>>
>> Hi,
>>
>> I just tested the latest 20.04 release in the hope that the installer
>> improved. It did not improve. The desktop installer really needs work.
>>
>> It prefers plain text vs encryption which is not appropriate these days
>> and makes Ubuntu insecure. You have to choose extra options to get an
>> encrypted setup. If yo do so, it is not possible to create a setup which
>> uses multiple disks.
> 
> Which layout do you expect to be done, when trying to do both
> encryption and multiple disks?
> 
> Today, we create luks and create LVM inside that. If you want, you can
> add luks on additional drives, and add them as PVs to your LVM as
> well. So it is possible to do this as a post-install task. I'm not
> sure how to design, or explain what happens when you do that. As one
> will be promoted to unlock each encrypted drive separately.

My first idea was that it should be possible to decrypt multiple devices
with one password. I couldn't figure out how to do it.

I ended with a key file on the boot device used to decrypt the mounted
device. I also used LVM, PV, additonal partition and mounted it. This is
somthing the installer could do.
It might be possible to add the additional space to the LV. Never tried
that and it doubles the failure propability.

> 
>> A different issue is the plain text /boot partition required. This is
>> also insecure and unnecessary. This partition reserves fixed space for
>> the Kernels, causing issues if to small or wasting space if to big. The
>> installer allows it to be any size and doesn't propose a size. Since
>> GRUB can boot LUKS devices this is unnecessary.
> 
> Unfortunately this is not true. We default to the stronger LUKS2 which
> the current grub shipped in 20.04 has no support to unlock. grub only
> can unlock the significantly less secure LUKS1 which we no longer
> recommend for people to use.

You should check the lates GRUB versions, it supports version 2 now. I
saw the merge request some time ago now.

> Instead of relying on encryption, we instead use modern firmware
> features of ensuring Secureboot & Measured Boot & Lockdown. The only
> bootloaders and kernels you  can boot, are those that are chained to
> Canonical Master CA UEFI offline certificate, and by default only
> signed kernel modules can be loaded. Thus although /boot is not
> encrypted, it is impossible to boot untrusted artefacts off it. If one
> has TPM one can take further attestation measures to prevent kernel
> cmdline being modified too. In the context of enforced secureboot &
> enforcing signed kernel modules, what security issues do you see with
> unencrypted /boot ?

The first issue is complexity. These complex systems are hard to proove
to be save. I once installed a mainline kernel and was able to boot
something unsecure. And yes there was a message, but I doubt it is hard
to get rid of it. The last issue is that you have a fixed size boot
partition, and ubuntu update fails miserably if it runs full.

>> The third major issue the missing support for file systems supporting
>> snapshots.
>>
> 
> Desktop installer offers LVM & ZFS installation options, with
> snapshots integration in apt and backup software out of the box. Are
> snapshots as provided by zfs or lvm not sufficient for you?

ZFS has its own issues. It has no support of the Linux community because
of the legal issues. It is known to consumes a lot of memory. It is
still experimental. Therefore I never really tried. BTRFS is there for
quite some time and it is supported by more than one vendor. Works well
for me. Only downside is the lacky Ubuntu support, e.g. for swapfiles.

>> Linux itself supports all of the mentioned short comings. It is possible
>> to create encrypted multi disk setups. It is also possible to boot
>> directly from the encrypted partition. It is possible to use for example
>> BTRFS as root file system, gaining compression and snapshots. It is
>> possible to have a swap file on a BTRFS partition. Everything is
>> available and the installer should be able to glue it together.
>>
>> With ZFS on the doorstep it is time to renovate the installer to support
>> the new features of modern file systems and bring security i to up to date.
>>
> 
> Instead we integrated ZFS into our desktop installer, which does
> support encryption, and is superior to btrfs in our opinion. Why use
> btrfs, when zfs is offered out of the box?

I'm not a file system expert to really decide about superiority. Since
Ubuntu was not able to convince any other major distribution nor the
kernel developers I do have doubts. For a desktop most of the advanced
ZFS features seem to be useless.

> 
>> My question is. Who is in charge for the installer?
>>
> 
> Ubuntu 20.04 LTS Desktop installer offers the features you deem
> essential, is something was not clear in the UI for you to discover
> them?

Adding additional encrypted drives you called a post-install process,
therfore the installer doesn't support it. Neither does it support
encrypted /boot dir. The snapshots and encryption are supported with the
experimental ZFS support only.

You mean users are forced to use experimental ZFS to use encryption on
multiple device? What if I don trust ZFS and want the prooven LUKS
encryption? I have choosen a LTS distribution because I don't want
experimental software. Especially not when it comes to file system and
encryption. That's not an UI issue.