[security][FIPS][15-SP4][15-SP5] Implement & Integrate LUKS test case into openQA
Test Case 1769936: FIPS: Full disk encryption with LUKS (including /boot)
Test Case 1769937: FIPS: Full disk encryption with LUKS (separate unencrypted /boot)
I think you could take this ticket as you have some LUKS test experience. And these 2 cases can be test cases an be implemented in the same time as they are the similar testing area.
You could still need to investigate it and try this on TW first as you are unable to access OSD currently. And also I think the configure/UI style would be some different between SLE and TW.
Updated by pstivanin about 1 year ago
Fully encrypt a system including /boot, it would look somewhat like this: * MBR (grub2) * /dev/vda1 -> LUKS -> LVM PV -> LVM VG -> LVM Volumes -> file systems (including /boot with kernel and initrd) For this to work, grub2 needs to be able to open LUKS volumes by itself (without initrd) otherwise it could not even read the kernel and initrd. Luckily the grub2 in our product is able to do this, and our installer does the right thing. 1, Install SLES15 SPx -- Input kernel option "fips=1" for installation (or skip here but enable fips=1 after installation) -- Click on "Edit Proposed Settings" and select "Encrypted LVM-based Proposal" at Suggested Partitioning, setup password, at least 8 characters -- Click on "OK" -- Click on "Expert Partitioner..." -- Right-Click on "/dev/sda1" (or /dev/sda1, the separate partition for /boot) -> Select "Delete" -> "Yes" The partition map looks like: /dev/vda /dev/vda1 Linux LVM /dev/system LVM2 system /dev/system/root LV BtrFS / /dev/system/swap LV Swap swap -- Click on "Accept" to finish the disk partitioning. 2, Boot SLES15 SPx from harddisk -- Password will be asked for twice: * The first time is required by grub, before the grub menu displayed: "Attempting to decrypt the master key....Enter passphrase for hd0,msdos1(xxx):" * The second time is required by initrd when mounting the volume: "Please enter passphrase for disck cr_vda2!" 3, Check FIPS is enabled
Fully encrypt a system, but keep /boot on a separate unencrypted partition, it looks like the following: * MBR (grub2) * /dev/vda1 mounted to /boot (unencrypted!) with kernel and initrd * /dev/vda2 -> LUKS -> LVM PV -> LVM VG -> LVM Volumes -> file systems Here the bootloader just loads the unencrypted (!) kernel and initrd from /boot. That initrd has support for encrypted volumes using LUKS and is able to open it and continue booting. 1, Install SLES15 SPx -- Input boot option: fips=1 -- Select "Encrypted LVM-based Proposal" at Suggested Partitioning, setup password 2, Boot SLES15 SPx from harddisk -- Input password to mount the disk partitions 3, Check FIPS is enabled Note: Do not pass "fips=1" to installer boot option, seems installer doesn't support fips mode yet, see bsc#985969 Workaround is enable fips mode after installation: update grub.cfg and reboot.
Updated by pstivanin about 1 year ago
- Subject changed from [sle][security][backlog][FIPS]Implement & Integrate LUKS test case into openQA - make sure test can pass in new official build to [security][FIPS] Implement & Integrate LUKS test case into openQA - make sure test can pass in new official build
- Status changed from New to In Progress
- Assignee set to pstivanin
- Estimated time deleted (
- Status changed from Workable to In Progress
- % Done changed from 0 to 10
I don't think LVM is needed in this case, as it only adds more complexity. I'll do some local testing to see how the installer behaves in all cases. Boot is encrypted by default when selecting disk encryption in the installer. Separate boot can be created in the expert partitioner.
The system boots even with EFI and partitions set with separate boot and only with
/ encrypted. This is a very nice surprise, since the installer had to do some specific grub configuration and initramfs has to have support for this as well. I was expecting to have to deal with quirks like this. Very nice.
Note: Do not pass "fips=1" to installer boot option, seems installer doesn't support fips mode yet, see bsc#985969 Workaround is enable fips mode after installation: update grub.cfg and reboot.
The mentioned https://bugzilla.suse.com/show_bug.cgi?id=985969 seems to be fixed now. It is confirmed working in the installer in both BIOS and UEFI (15-SP4 x86).
# cat /proc/sys/crypto/fips_enabled 1
It seems like the tests are already written:
although they are never scheduled and tests from
yast/encryption/ are scheduled instead. I reckon we can delete the copies in
security/encryption/, provided the yast versions work.
After talking with people from QE-YAM (yast), we concluded that it would be better to maintain our own clones of the schedules, because they are planning on rewriting them, which would most likely break for us.
Explained by Joaquin Rivera:
don't depend on us, we soon will break them, because we are using a new features for scheduling, where instead of a list of test modules we have keys for phases of the installation and a default file.
each squad is better to have their own copy, we favor that each squad work independently on those, than to try to be very efficient with one file, the second doesn't help, because a minimal change can break stuff in other squad.
- % Done changed from 80 to 50
We have merged the first part of tests for separate boot testing on SP4 and SP5 x86 platforms. I will be extending the tests further and replacing the old schedules.
Rewritten tests to cover more platforms: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17182
Waiting to be scheduled.