V2P and Encryption — 1
Although an improvement, I remained unsatisfied after creating a 32-bit virtual machine (VM) on my T400 laptop for remote access to work systems, I decided to convert the virtual system to physical (V2P).
The 32-bit VM responded better than the 64-bit VM, but only nominally. I presumed that running directly from the new SSD would be much snappier. Running directly from the SSD meant I could still use the 64-bit system. Running directly from disk means not allocating additional RAM to a VM, which reduces overhead with the older CPU and RAM.
I have converted virtual systems to physical but this time I needed to encrypt the system. That was the original reason for the VM — the system needed encryption to protect confidential and sensitive data.
Using an encrypted partition is new territory for me. Having never used disk encryption, the effort will be an adventure in trial-and-error. I am not a genius and do not play one on TV.
With my VMs I have been using the built-in VirtualBox encryption. Converting to a physical system requires a different method of encryption. Like a VM, I want the converted VM to be self-contained and isolated. That does not mean encrypting the entire disk, just the respective partitions. To do that I want to use a swap file rather than a swap partition. A swap partition must be encrypted to provide security. Easier to use a swap file.
A common approach is to use Logical Volume Management (LVM), which would allow using a swap partition. I did not want to do that. LVM creates layers of abstraction that I prefer avoiding.
I already had Slackware 14.2 64-bit installed on the laptop. I did not want to remove that system because that is what I prefer for my personal use. I use GRUB rather than LILO. I needed to convert the VM but also configure GRUB to chain load the encrypted system.
This was not going to be a simple point-clicky operation.
Use a Swap File
I configured the VM to use a swap file rather than a swap partition. The VM was using two partitions, one ext4 system and the swap partition. I was using a 1 GB swap partition. I had almost 9 GB of free space on the root partition. Plenty of space for a 1 GB swap file.
fallocate -l 1g /var/swapchmod 600 /var/swapmkswap /var/swapswapon /var/swap- Edit
/etc/fstab:/var/swap swap swap defaults 0 0
I rebooted. I ran cat /proc/swaps (same as swapon -s) to verify the swap file was mounted as well as the original swap partition.
I edited /etc/fstab not to mount the original swap partition. I rebooted. All looked good.
I booted the VM with a Live ISO. I removed the swap partition. I resized the system partition to the full disk.
There was a noticeable delay when booting with the local-premount service. The cause is a configuration looking for a swap partition, part of the resume from hibernation checks. I edited /etc/initramfs-tools/conf.d/resume to RESUME=none. I rebooted. That configuration change resolved the boot delay. The file can be deleted with the same successful result.
V2P Preps
On the VM I removed the built-in VirtualBox encryption.
I removed the VirtualBox Guest Additions. This is easy to verify by looking in the /opt directory.
In the VM I used the VirtualBox NAT network. As that would be unavailable in the final disk installation I installed NetworkManager.
As I would be using the Linux Unified Key Setup (LUKS) encryption, I installed the cryptsetup package in the VM.
I did not know whether compacting the disk would help with speeding up the conversion but I did that anyway.
Virtual to Physical (V2P)
I converted the VM to a physical disk image.
vboxmanage clonemedium $VDI.vdi $VDI.img --format raw
Where $VDI is the name of the VM.
Although only about half full, the VM used a 16 GB dynamic hard drive. As expected, after converting to a disk image the final file size was 16 GB.
Create a Physical Disk
A partition in a disk image file can be mounted using sector offset calculations. Such tricks make my head hurt. Instead, as I had converted the VM disk to a disk image file, I used dd to copy the image to a spare physical disk. I mounted the disk’s physical partition and browsed the contents to verify all was well.
Populate the New Partition
Before encrypting I wanted to ensure I could boot the new Ubuntu system. I then would know I had the grub.cfg files configured correctly minus the encryption details.
On the laptop I created a new 20 GB partition. I copied the contents of the physical partition to the new laptop partition.
With my Slackware system I edited the Ubuntu system /etc/fstab to use the new block UUID.
Configure GRUB
In my first effort I copied and pasted the appropriate Ubuntu grub.cfg menu entry snippets into the Slackware grub.cfg. I modified the UUID and partition location information, such as changing msdos1 to gpt7.
I rebooted. The system booted but mounted the existing swap partition as swap. In the Ubuntu system I ran the following command and rebooted:
systemctl mask dev-sda3.swap
Comfortable I could boot into the V2P system, I wanted to install grub to the partition and chain load the boot process between the two boot loaders.
menuentry ‘Ubuntu MATE 16.04 64-bit’ --class gnu-linux --class gnu --class os’ {
set root=(hd0,7)
chainloader +1
boot
}
Upon rebooting I selected the Ubuntu MATE option and was greeted with a second GRUB menu — the Ubuntu GRUB menu. The system booted as expected.
I copied the modified Ubuntu /boot/grub/ files to the temporary hard drive.
Encrypting
Encrypting a partition destroys all data. Encrypting the partition is required before installing or copying files. That means repeating the previous steps with additional changes for encryption.
The stock Slackware has the encryption tools installed. The LUKS encryption system uses the Linux device mapper.
I deleted the previous unencrypted /dev/sda7 partition. Using gparted I created a 10 GB /dev/sda7 that would be my encrypted /home partition. I created and formatted a 20 GB /dev/sda8 that would be my system partition.
I encrypted /dev/sda7.
cryptsetup -y -v luksFormat /dev/sda7
I used the same passphrase I had been using with the built-in VirtualBox encryption.
I opened the encrypted partition and formatted to ext4.
cryptsetup luksOpen /dev/sda7 lukssda7
mkfs.ext4 /dev/mapper/lukssda7
Excepting the contents of /home, I copied the contents of the spare disk partition to the laptop /dev/sda8.
In the mounted /dev/sda8 I created an empty home directory.
I mounted the encrypted partition and copied the contents of the spare disk /home to that partition.
mount /dev/mapper/lukssda7 /mnt/sdy
cp -a -v /mnt/sdb1/home/* /mnt/sdy/
The reformatting changed the UUID of the partition. I edited the Ubuntu grub.cfg. I edited the Slackware grub.cfg.
I edited the chainloader menu entry to include encryption related modules.
menuentry ‘Ubuntu MATE 16.04 64-bit’ --class gnu-linux --class gnu --class os’ {
insmod diskfilter
insmod cryptodisk
insmod luks
insmod ext2
insmod chain
cryptomount hd0,gpt7
chainloader +1
boot
}
I rebooted but used my copied grub.cfg snippet menu option rather than the chainloader menu entry.
In the Ubuntu system I edited /etc/default/grub.
GRUB_ENABLE_CRYPTODISK=y
I installed GRUB to the system partition.
grub-install /dev/sda7 --force
I edited the Ubuntu /etc/fstab to mount the encrypted /home partition.
/dev/mapper/lukssda7 /home ext4 defaults,nboatime 0 2
I rebooted and used the chain loader menu option. I was greeted with the Ubuntu GRUB menu. I booted to run level 3. As I don’t use a boot splash, I saw the prompt to enter the LUKS passphrase. I typed the password.
I logged in and verified I could access the files in /home.
Networking
Previously I booted the laptop with Slackware and launched the work-related VM. As this no longer was the case, I needed to configure NetworkManager for the new system. The easy solution was booting into Slackware, mounting the Ubuntu system partition /dev/sda8, and sync the respective files from the Slackware /etc/NetworkManager to the Ubuntu /etc/NetworkManager directory.
I rebooted into Ubuntu run level 3. With nmcli c I verified the tool had connected to the home LAN.
I rebooted again but this time into run level 5 with the GUI login manager.
Loose Ends
At this stage I was pleased. I stubbed my toes many times to understand the sequence of events. Despite my good feeling, I saw a few loose ends.
I needed to install network-manager-openvpn so I could access the home VPN when at work.
Ubuntu auto-detects other partitions and the MATE Caja file manager populates the Places menu with those partitions. Although I do not store anything confidential or sensitive on the Slackware partitions, I did not want to see the partitions. I created /etc/udev/rules.d/99-hide-partition.rules.
KERNEL=="sda1", ENV{UDISKS_IGNORE}="1"
KERNEL=="sda2", ENV{UDISKS_IGNORE}="1"
KERNEL=="sda3", ENV{UDISKS_IGNORE}="1"
KERNEL=="sda4", ENV{UDISKS_IGNORE}="1"
KERNEL=="sda5", ENV{UDISKS_IGNORE}="1"
KERNEL=="sda6", ENV{UDISKS_IGNORE}="1"
I configured similarly on the Slackware side to not see the two Ubuntu partitions.
I needed to disable the trackpad and test the Fn keys. I needed to test my shell scripts used in my work flow when I use the laptop at work. In the end the encrypted system worked just fine.
Caveats
I am uncomfortable with the Ubuntu system partition not being encrypted. A malicious hacker could access the Ubuntu system partition and modify the configuration. For example, changing the NetworkManager configuration to save passwords and pass phrases. Not good since NetworkManager saves that information in clear text.
Another caveat is the swap file is not encrypted.
The only way I know to backup an encrypted partition is with dd. In hindsight I could create a smaller /home partition to reduce backup times.
My desktop system still uses the VMs for remote access to work systems. This is more convenient than dual booting, plus I get to run Slackware as my base system. That approach has worked well for me for many months. The office system has a 4-core CPU and 16 GB of RAM. Lots of muscle for running VMs.
Dual booting on the laptop is a better approach for performance. I do not use the laptop at home for remote access because the office desktop is available. Mostly the laptop is used in the field at work where I do not need the Slackware system or when at home, just surfing the web. Dual booting is not irritating in that sense.
Happily, installing directly to the SSD is indeed much faster than running the 32-bit VM.
Posted: Category: Tutorial, Usability Tagged: General
Next: V2P and Encryption — 2
Previous: Simple PuTTY Usability Tweaks