Installer parses and modifies pre-existing partitions even if given disk is not selected for installation

[marmarek]

Qubes OS version (e.g., R3.2):

R3.2, R4.0

--

Expected behavior:

Installer ask the user what disks should be used for installation and only modify selected disks, and only in a way configured in installer (do not touch partition not used as installation target).
Actually main anaconda screen contains phrase: "We won't touch your disks until you click 'Begin Installation'.". This is not true.

Actual behavior:

Before showing main anaconda screen, it "probe for storage". This include:

• Running fsck on all found partitions, LVM volumes etc. According to code comment, it is to obtain reliable information about possible partition resize
• Mounting each found Linux partition, and parse some files there (/etc/fstab, /etc/os-release). This is supposedly also to provide more information about those partitions...

General notes:

Besides performance impact, this have serious other implications:

• can lead to data loss - for example if some of those partitions are signed with dm-verity (like in Chromium OS, or Heads), or belongs to hibernated system
• security aspect: previously installed, malicious OS can try to compromise some of those parses by leaving specifically crafted data on disk

Related issues:

Upstream issues:

• https://bugzilla.redhat.com/show_bug.cgi?id=1170803 (about modifying disks without consent) - accepted as a blocker for Fedora 27, after sitting there for over 2 years)
• https://bugzilla.redhat.com/show_bug.cgi?id=1374983 (about performance)
• https://bugzilla.redhat.com/show_bug.cgi?id=1268700 (about performance)

Proposed half-solution

Modifying this part of installer from downstream distribution position is quite hard - require forking some more packages. Until upstream issue got fixed, add appropriate info to installation guide. Something like:

Warning: installer will try to access all existing partitions, running fsck there and mounting them. It is recommended to physically disconnect unrelated disks during the installation. If installation target contain potentially compromised system, it is also recommended to wipe the disk before launching the installer.

[andrewdavidwong]

Oh, wow. I agree with your "proposed half-solution." I'd just add that we want to stress that this is an upstream bug.

[andrewdavidwong]

Oh, wow. I agree with your "proposed half-solution." I'd just add that we want to stress that this is an upstream bug.

[andrewdavidwong]

Added a warning to the installation guide.

[andrewdavidwong]

Added a warning to the installation guide.

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-3.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-3.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[andrewdavidwong]

Updated the documentation warning to specify that the issue affects only 3.2 and is fixed in 4.0.

[andrewdavidwong]

Updated the documentation warning to specify that the issue affects only 3.2 and is fixed in 4.0.

[marmarek]

The fix prevent calling fsck, but do not prevent mounting partitions.

[marmarek]

The fix prevent calling fsck, but do not prevent mounting partitions.

[andrewdavidwong]

@marmarek: If you expect that this will be fixed before the 4.0 stable release, I will leave the documentation as-is (stating that the issue is fixed in 4.0). Otherwise, I can update the documentation to clarify that it is only partially fixed in 4.0.

[andrewdavidwong]

@marmarek: If you expect that this will be fixed before the 4.0 stable release, I will leave the documentation as-is (stating that the issue is fixed in 4.0). Otherwise, I can update the documentation to clarify that it is only partially fixed in 4.0.