Dejice Jacob: University of Glasgow

A gentoo installation story - continued!

Dejice Jacob — Sun, 19 Jan 2025 20:14:21 GMT

The birth of a Gentoo Linux KDE Desktop

I have previously journaled (Part-I) my attempt to create an encrypted Gentoo Linux desktop. Please follow that first. It was a little more involved than I expected. I had to revisit some of the steps one or two times. Some of the steps in that post might better fit in this post. But hindsight is a wonderful thing. Now we come to building out what the general public think of as a computer (the Desktop).

Install some useful utilities

localost / $ eselect profile list # to get a list of desktop profiles 
localost / $ eselect profile set <KDE-openrc>  # I will also setup i3 tiling window manager
localost / $ echo "Europe/London" > /etc/timezone
localost / $ emerge --sync 
localost / $ emerge --quiet-build --ask --config sys-libs/timezone-data 
localost / $ emerge --quiet-build --ask app-misc/screen sys-process/htop

Setup WiFi (Optional)

In (Part-I), I already had ethernet and used that for installation. However, if WiFi is something that is required, then the following instructions should set up WiFi. Bear in mind that WiFi drivers could be missing from your kernel configuration. Searching the Gentoo forums for a similar issue would be helpful.

I will be installing network-manager later on and will have to disable both dhcpcd and wpa-supplicant. If we forget, then we will have two instances of DHCP and WiFi daemons duelling each other.

localost / $ emerge --quiet-build --ask net-misc/dhcpcd
localost / $ emerge --ask --verbose net-wireless/wpa_supplicant
localost / $ cp /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks/
localost / $ bzcat  /usr/share/doc/wpa_supplicant-<ver-no>/wpa-supplicant.conf.bz2 > /etc/wpa_supplicant/wpa_supplicant.conf

Almost all variations of a wpa-supplicant configuration can be obtained from "/usr/share/doc/wpa_supplicant-/wpa_supplicant.conf.bz2". Uncomment the following in /etc/wpa_supplicant/wpa_supplicant.conf.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
eapol_version=1
ap_scan=1
fast_reauth=1

Also generate the network connection parameters and insert into wpa_supplicant.conf using wpa_passphrase and remove every other configuration in that file. In case you have a more complicated set-up, then you will have to configure this according to your setup.

localost / $ wpa_passphrase ${ssid} ${passphrase}  >> /etc/wpa_supplicant/wpa_supplicant.conf

Change the value of wpa_supplicant_args in /etc/conf.d/wpa_supplicant.conf to:

wpa_supplicant_args="-B -M -c/etc/wpa_supplicant/wpa_supplicant.conf"

Now add the dhcpcd and wpa_supplicant services to default runlevel and start the services.

localost / $ rc-update add dhcpcd default
localost / $ rc-update add wpa_supplicant default
localost / $ rc-service dhcpcd start
localost / $ rc-service wpa_supplicant start

Setting up NTP

Networking and "time" dependent programs require accurate date and time information. This is achieved by installing NTPD.

localost / $ emerge --ask net-misc/ntp
localost / $ rc-update add ntpd default
localost / $ rc-service ntpd start

Install the KDE desktop

While Wayland seems to be the future, I am still quite comfortable with the X server. It also helps that the i3wm window manager also is dependent on X-sever. The KDE meta-package is comprehensive and installs all the KDE applications and dependencies.

localhost / $ emerge --ask kde-plasma/plasma-meta

Ensure that the KDE display manager sddm is installed; then ensure that the "DISPLAYMANAGER" variable is set to sddm.

DISPLAYMANAGER="sddm"

Add the requisite services to openrc to start at boot,

localost / $ rc-update add dbus default
localost / $ rc-update add display-manager default
localost / $ rc-update add elogind boot

In my case, at this point, I found that just starting up the boot displaymanager from openrc did not get sddm to start. Rebooting the machine sorted the crashing display manager out.

Debugging: Install X-server

If there are any problems with bringing up KDE, using X-server to debug the issue is very useful. In case it was not already installed when KDE-meta was installed, start with installing X-server and driver packages.

localost / $ emerge --ask --verbose x11-base/xorg-drivers x11-base/xorg-server

To test out that the X-server is working correctly install a few X applications

localost / $ emerge -a x11-terms/xterm x11-apps/xclock x11-wm/twm
localost / $ startx   # to test if display server is working

Sidenote: Uninstall dhcp and wpa-supplicant

Keeping dhcpcd and wpa-supplicant running in the background led me to some incredibly annoying and hard to debug problems with networking. The KDE deskptop already installs NetworkManager and this will in turn call an instance of dhcp and wpa_supplicant. You do NOT need your own version fighting with it. So...

localost / $ rc-service stop dhcpcd
localost / $ rc-update del dhcpcd
localost / $ rc-service stop wpa_supplicant
localost / $ rc-update del wpa_supplicant

Congratulations!

If you have persevered with the process this far, congratulations! You should have a desktop machine that you have compiled from source. Obviously, I have cleverly hidden all the frustrating debug work that went into steps going wrong. Along with this, there are issues with drivers or kernel features required by some software component not being turned ON. However, that is what the incredible gentoo forums and wiki are for. Happy compiling and debugging.

An encrypted-boot gentoo installation story

Dejice Jacob — Sat, 11 Jan 2025 12:15:49 GMT

How I got to gentoo

Like many people, I have gone through a few linux distros in my lifetime. Over the span of two decades, I ended up going through OpenSuse → Ubuntu → Debian (Stable) → Debian (Testing) → Gentoo. I keep an eye on distributions quite often, but the motivation for moving distributions crosses a threshold when a major workflow or technology disruption occurs within the distribution. It also correlates with my (Slowly) increasing knowledge and comfort with delving into how systems are put together.

I moved from Ubuntu → Debian (Stable) when Ubuntu decided to develop Mir rather than developing for Wayland. I am always enthusiastic about new software being developed, if only to see what could have been. The vision of convergence between devices was a cool one and given the right circumstances, may have succeeded. However, any large scale surgery of this sort which veers off and does its own thing risks failure.

Another thing that philosophically did not sit right with me was the usage of snap packages. To me this felt like a way to reduce the pressure of maintenance in the short-term at the expense of long-term fragmentation. Desktop *nix distributions are not yet (it is now decade no.3 of trying to conquer the desktop) popular enough. I wish it was different (sigh)! Like any demand-supply equation, any let-up in the pressure to maintain library/API compatibility, in my opinion, would just lead to fragmentation and end-user frustration in the long-run.

So I decided to do the Ubuntu → Debian (Stable) switch. As I was using a slightly older laptop, and it had all the drivers and packages I needed, I wonder why I did not do this earlier (Doh)! After two of my upgrades between major Debian revisions ended up requiring re-installations, I heard of this amazing new term called rolling-distributions. (Please excuse the naïvete and yes, I really am that naïve)!

The next trigger to move was Debian's embrace of Systemd. I feel more comfortable with openRC which I think keeps better to the overall *nix philosophy. I had by now done enough systems level software development and debugging to no longer be afraid of doing silly things that break stuff (a little knowledge being dangerous and all that). Building a new system from ground up would be something that would allow me to explore and understand the guts of my own system.

Enter Gentoo

Keeping with the theme of going further upstream and closer to the source (wipe that smug Icarus image from your mind), the choice was between Linux from Scratch, Slackware and Gentoo. In the end, I went with Gentoo due to the package manager and the sheer amount of support and documentation on the website. It should help reduce the amount of debugging and maintenance work I have to do, while still making me feel like a proper computer scientist. Vanity and naïvete -- what could possibly go wrong?

Why ?!

This leads us onto the purpose of this blog. Installing gentoo is relatively easy but time consuming if we go through the relatively straightforward instructions in the marvellous Gentoo AMD64 handbook. However, I wanted to do a fully encrypted /boot drive as well and had to search around for various instructions. This is the command log (My Gentoo installation story) for my own personal notes. Someone else finding it useful is just a bonus. For more comprehensive information and various options, Each link in the subsections below are linked to the much more comprehensive information in the gentoo wiki.

Gentoo AMD64 installation with encrypted /boot

Obtaining and preparing the installation media

Very detailed instructions are already provided in the handbook and I don't have anything new to add. Switch off secure-boot in the BIOS and choose to boot from the USB drive that was just prepared. Once the laptop has been booted into the linux kernel and shows a root prompt, we will need to set up networking.

Partitioning the storage disks

I have a 16 GiB Laptop with 1TB of space on the SSD. I wanted to partition it with the following schema:

NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                  259:0    0 953.9G  0 disk
├─nvme0n1p1              259:2    0     2M  0 part
├─nvme0n1p2              259:4    0   512M  0 part
│ └─luks_boot            253:0    0   496M  0 crypt
├─nvme0n1p3              259:6    0   128M  0 part
└─nvme0n1p4              259:8    0 953.2G  0 part
  └─luks_root            253:1    0 953.2G  0 crypt
    ├─osvg-swap          253:2    0    8G  0 lvm   [SWAP]
    ├─osvg-gentoo--root  253:3    0    64G  0 lvm   /
    ├─osvg-gentoo--home  253:4    0    16G  0 lvm   /home
    └─osvg-data          253:5    0 865.2G  0 lvm   /media/data

Zap all pre-existing partitions on the disk.

livecd ~# sgdisk --zap-all /dev/nvme0n1

Ensure the first 1MiB is left for grub to be written into raw device head. So we create a 1MiB partition with offset=1MiB.

livecd ~# sgdisk  --new=1:1M:+2M /dev/nvme0n1
livecd ~# sgdisk  --new=2:0:+512M /dev/nvme0n1
livecd ~# sgdisk  --new=3:0:+128M /dev/nvme0n1    
livecd ~# sgdisk  --new=4:0:0 /dev/nvme0n1

Change the names of the partitions and their filesystem types in the GPT partition table. A list of partition types can be obtained with sgdisk -L.

livecd ~# sgdisk  --typecode=1:ef02 --typecode=2:8300 --typecode=3:ef00 --typecode=4:8300 /dev/nvme0n1
livecd ~# sgdisk --change-name=1:GRUB --change-name=2:/boot --change-name=3:EFI-SP --change-name=4:OS /dev/nvme0n1

Encrypt the /boot partition with a password. While it is certainly more robust to have a separate Keyfile stored on another USB flash drive, it is cumbersome to carry around. Also, if you forget it or lose it, then it can be a pain. I am just going to use a plain old password for this in this case. Additionally, grub can not yet decrypt keys in the default LUKS2 format (argon2id) and requires the key to be in the LUKS1 default format of PBKDF2. So the /boot partition is formatted with LUKS1. I will maybe write up a detached header version in a future post.

livecd ~# cryptsetup luksFormat --key-size=512 --type=luks1 /dev/nvme0n1p2

Format the /boot and efi-sp partitions

livecd ~# cryptsetup open /dev/nvme0n1p2 /dev/mapper/luks_boot
livecd ~# mkfs.ext4 -L boot /dev/mapper/luks_boot
livecd ~# mkfs.vfat -n EFI-SP -F 16 /dev/nvme0n1p3

To obtain an encrypted /root, /home and swap partition, I decided to use Logical Volume Management (LVM) on a LUKS encrypted partition. With experience, I can say that if you intend on using the KDE desktop, the machine should ideally have 32GB of RAM. Some packages such as firefox, the qtwebkit renderer etc require greater than 16GB of RAM. This would then influence the amount of swap space that you should keep aside. Since I have 32GiB of RAM, and I do not want suspend, only 8GiB of swap space is allocated. The beauty of LVM is that this can be resized in the future if required.

livecd ~# cryptsetup luksFormat --key-size=512 --key-slot=1 /dev/nvme0n1p4 
livecd ~# cryptsetup open /dev/nvme0n1p4 luks_root    
livecd ~# pvcreate /dev/mapper/luks_root  # Create a Physical volume on the decrypted device
livecd ~# vgcreate osvg /dev/mapper/luks_root  # Create a volume group on the Physical volume
livecd ~# lvcreate -L 8G -n swap osvg  # Create swap space on the encrypted LVM 
livecd ~# lvcreate -L 64G -n gentoo-root osvg  # Create /root on the encrypted LVM 
livecd ~# lvcreate -L 16G -n gentoo-home osvg  # Create /home on the encrypted LVM 
livecd ~# lvcreate -l 100%FREE -n data osvg  # Create a separate data partition

Format the partitions created in the LVM.

livecd ~# mkswap -L swap /dev/mapper/osvg-swap 
livecd ~# mkfs.ext4 -L root /dev/mapper/osvg-gentoo--root
livecd ~# mkfs.ext4 -L home /dev/mapper/osvg-gentoo--home
livecd ~# mkfs.ext4 -L data /dev/mapper/osvg-data

Now mount the encrypted drives to various directories

mkdir -p /mnt/gentoo/{root,home,data}
mount /dev/mapper/osvg-gentoo--root /mnt/gentoo/root
mount /dev/mapper/osvg-gentoo--home /mnt/gentoo/home
mount /dev/mapper/osvg-data /mnt/gentoo/data

Configuring the network

I already have an ethernet cable to connect, so I did not require to set up WiFi. Gentoo already has the net-setup utility to help with setting up WiFi. The network interface names can be obtained using the ip link command. Set-up is through a fairly easy menu driven ncurses style interactive interface.

livecd ~# net-setup

For ethernet, configure the wired ethernet interface (starts with enp...)
In the case of WiFi, choose wireless WiFi interface (starts with wlp...)

Make sure the time of the system is accurate. I utilised a simple NTP client (chronyd) to correct the time.

livecd ~# chronyd -q

Obtaining the Stage-3 Installation files

I like openrc and chose the desktop-openrc profile for the stage-3 tarball. Use the livecd built-in ncurses browser to obtain the stage-3 tarball. Alternatively download it on another PC and transfer via another USB device.

Setup base root filesystem, configure portage and gentoo base

Assuming the stage-3 tarball is in /mnt/gentoo/data untar it to the target storage-device's /root directory. In our case, we have mounted it to /mnt/gentoo/root.

livecd ~# cd /mnt/gentoo/data
livecd ~# tar -Jxpvf stage3_tarball.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/gentoo/root  
livecd ~# cd  /mnt/gentoo/root
livecd ~# cp --dereference  /etc/resolv.conf /mnt/gentoo/root/etc/resolv.conf 
livecd ~# echo MAKEOPTS=\"-j$(nproc)\" >> /mnt/gentoo/root/etc/portage/make.conf
livecd ~# echo ACCEPT_KEYWORDS=\"amd64\" >> /mnt/gentoo/root/etc/portage/make.conf
livecd ~# echo USE=\"udev lvm dbus X pulseaudio networkmanager clang\" >> /mnt/gentoo/root/etc/portage/make.conf

Add the CPU flags for your host to /mnt/gentoo/root/etc/portage/make.conf. Make sure you replace the newly added line to the format CPU_FLAGS_X86="aes .....".

livecd ~# echo $(cpuid2cpuflags) >> /mnt/gentoo/root/etc/portage/make.conf

Now add the video-cards depending on your machine. On this machine, I had an AMD video card.

livecd ~# echo VIDEO_CARDS=\"amdgpu radeonsi\" >> /mnt/gentoo/root/etc/portage/make.conf

Add some miscellaneous devices as well. libinput provides input handling for display servers.

livecd ~# echo INPUT_DEVICES=\"libinput\" >> /mnt/gentoo/root/etc/portage/make.conf
livecd ~# echo SANEBACKENDS=\"hp\" >> /mnt/gentoo/root/etc/portage/make.conf

Within the portage configuration file /mnt/gentoo/root/etc/portage/make.conf update the value of the variable COMMON_FLAGS to COMMON_FLAGS="-march=native -O2 -pipe" Also select from the worldwide mirrors to download software from.

livecd ~# mirrorselect -i -o >> /mnt/gentoo/root/etc/portage/make.conf

Mount the system files required to prepare the target computer's chroot environment.

livecd ~# mount --types proc /proc /mnt/gentoo/root/proc
livecd ~# mount --rbind /sys /mnt/gentoo/root/sys
livecd ~# mount --make-rslave /mnt/gentoo/root/sys
livecd ~# mount --rbind /dev /mnt/gentoo/root/dev
livecd ~# mount --make-rslave /mnt/gentoo/root/dev
livecd ~# mount --bind /run /mnt/gentoo/root/run
livecd ~# mount --make-slave /mnt/gentoo/root/run

Enter the chroot environment.

livecd ~# umount /mnt/gentoo/home /mnt/gentoo/data
livecd ~# chroot /mnt/gentoo/root /bin/bash
livecd ~# source /etc/profile
livecd ~# export PS1="(chroot) ${PS1}"
(chroot) livecd ~# export PS1="(chroot) ${PS1}"
(chroot) livecd ~# mkdir -p /home /media/data
(chroot) livecd ~# mount /dev/mapper/osvg-gentoo--home /home
(chroot) livecd ~# mount /dev/mapper/osvg-data /media/data
(chroot) livecd ~# swapon /dev/mapper/osvg-swap

Prepare the EFI System Partition.

(chroot) livecd ~# mount /dev/mapper/luks_boot /boot
(chroot) livecd ~# mkdir -p /boot/efi 
(chroot) livecd ~# mount /dev/nvme0n1p3 /boot/efi

Synchronise emerge's software package list with upstream mirrors

(chroot) livecd ~# emerge-webrsync

Setup Locale Details

(chroot) livecd ~# echo "Europe/London" > /etc/timezone
(chroot) livecd ~# echo "C.UTF8 UTF-8" >> /etc/locale.gen
(chroot) livecd ~# echo "en_GB ISO-8859-1" >> /etc/locale.gen
(chroot) livecd ~# echo "en_GB.UTF-8 UTF-8" >> /etc/locale.gen
(chroot) livecd ~# locale-gen
(chroot) livecd ~# env-update

Configuring the Linux Kernel

Obtain all kernel related gentoo packages.

(chroot) livecd ~# mkdir -p /etc/portage/package.license 
(chroot) livecd ~# echo "sys-kernel/linux-firmware linux-fw-redistributable" >> /etc/portage/package.license/kernel
(chroot) livecd ~# emerge --ask --quiet-build sys-kernel/linux-firmware sys-fs/cryptsetup sys-kernel/gentoo-sources sys-kernel/genkernel 
(chroot) livecd ~# eselect kernel set 1  # this should link /usr/src/linux to current kernel source
(chroot) livecd ~# echo "sys-boot/grub:2 device-mapper" > /etc/portage/package.use/grub2
(chroot) livecd ~# emerge --ask --quiet-build sys-boot/grub sys-fs/genfstab
## Ensure all the relvant drives (including swap are already mounted / turned on
(chroot) livecd ~# genfstab -Up / >> /etc/fstab 
## add noauto to the /boot and /boot/efi mount-points in /etc/fstab

Generate a LUKS key and add the generated key to the block device holding the encrypted partition. In my case, this was luks_boot (/dev/nvme0n1p2) and optionallyluks_root (/dev/nvme0n1p4). This will be the key that is used by the kernel-initramfs to decrypt and mount the encrypted LVM volume and (optionally) the /boot partition. There is a good argument to not automatically decrypt the /boot partition. This is why I have decided it is optional. Remember: We are adding this newly generated key to Key-slot:0 of luks_root -- this is why we carefully added the original-key during disk-partitioning in Key-slot:1. Using Key-slot:0 will make it faster during actual booting and each key is tried in sequence. link.

(chroot) livecd ~# mkdir -p /etc/luks/mnt/key
(chroot) livecd ~# dd if=/dev/urandom of=/etc/luks/mnt/key/boot_os.keyfile bs=4096 count=1
(chroot) livecd ~# chmod u=rx,go-rwx /etc/luks
(chroot) livecd ~# chmod u=r,go-rwx /etc/luks/mnt/key/boot_os.keyfile
(chroot) livecd ~# cryptsetup --key-slot=0 /dev/nvme0n1p4  /etc/luks/mnt/key/boot_os.keyfile  # luks_root
(chroot) livecd ~# cryptsetup --key-slot=1 /dev/nvme0n1p2  /etc/luks/mnt/key/boot_os.keyfile  # luks_boot
(chroot) livecd ~# echo "luks_boot UUID=$(blkid -s UUID -o value /dev/nvme0n1p2) /etc/luks/mnt/key/boot_os.keyfile luks,discard" >> /etc/crypttab
(chroot) livecd ~# echo "luks_root UUID=$(blkid -s UUID -o value /dev/nvme0n1p4) /etc/luks/mnt/key/boot_os.keyfile luks,discard" >> /etc/crypttab

NOTE: The key should be generated in a directory with the following pattern ${INITRAMFS_OVERLAY}/mnt/key. The genkernel tool when provided the INITRAMFS_OVERLAY variable will use this overlay within its filesystem. The kernel will then look for the internal key in /mnt/key.

While you could spend a long time configuring the kernel, I think it is easier to use genkernel to generate a kernel with a lot of options. We can always slim down the kernel afterwards. We can see the list of kernels with eselect kernel list.

(chroot) livecd ~# eselect kernel set 1

Set-up the following configurations in /etc/genkernel.conf. NOTE: Without the INITRAMFS_OVERLAY, the initramfs kernel cannot decrypt the enncrypted block device holding the LVMs for /root, /home etc.

NOCOLOR="false"
LVM="yes"
LUKS="yes"
GK_SHARE="${GK_SHARE:-/usr/share/genkernel}"
CACHE_DIR="/var/cache/genkernel"
DISTDIR="${GK_SHARE}/distfiles"
LOGFILE="/var/log/genkernel.log"
LOGLEVEL=1
ZFS="no"
BTRFS="no"
XFSPROGS="no"
DEFAULT_KERNEL_SOURCE="/usr/src/linux"
INITRAMFS_OVERLAY="/etc/luks"

Now execute genkernel and prune as much of the kernel config that you don't need before executing. (Ensure that /boot and /boot/efi are mounted)!

(chroot) livecd ~# genkernel --menuconfig --luks --lvm --no-zfs all

Configuring the GRUB bootloader

Ensure the following settings are inserted into the Grub configuration file in /etc/default/grub

GRUB_DISTRIBUTOR="Gentoo"
GRUB_TIMEOUT=3
GRUB_TIMEOUT_STYLE=menu
GRUB_DISABLE_LINUX_PARTUUID=false
GRUB_PRELOAD_MODULES="part_gpt part_msdos lvm"
GRUB_CMDLINE_LINUX_RECOVERY="recovery"
GRUB_ENABLE_CRYPTODISK=y

Also add the commandline for the linux kernel during boot before downloading and installing grub

(chroot) livecd ~# echo GRUB_CMDLINE_LINUX=\"keymap=uk dolvm crypt_root=UUID=$(blkid -s UUID -o value /dev/nvme0n1p4) root_key=boot_os.keyfile root_trim=yes resume=/dev/osvg/swap\" >> /etc/default/grub
(chroot) livecd ~# emerge --ask --quiet-build sys-boot/grub
(chroot) livecd ~# mkdir /boot/grub
(chroot) livecd ~# grub-mkconfig -o /boot/grub/grub.cfg 
(chroot) livecd ~# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id="grub"

This should install various bootloader stages in their respective locations. Set keymap=uk in the file /etc/conf.d/keymaps. Otherwise, a recovery shell dropping you into a different keymap can be frustrating for passwords and debugging in a shell.

Preparing to reboot into our newly installed bare-bones system.

We are now ready to shutdown and reboot into our newly installed system. Unmount all the mount points, bind-mounts and dmcrypt. First set a root password for the new system. Then unmount all our devices.

(chroot) livecd ~# passwd     #Set new password
(chroot) livecd ~# umount /boot/efi
(chroot) livecd ~# umount /boot
(chroot) livecd ~# cryptsetup close luks_boot 
(chroot) livecd ~# swapoff /dev/mapper/osvg-swap
(chroot) livecd ~# umount /media/data /home
(chroot) livecd ~# exit
livecd ~# umount /mnt/gentoo/root/proc
livecd ~# umount --recursive /mnt/gentoo/root/dev /mnt/gentoo/root/sys /mnt/gentoo/root/run
livecd ~# shutdown -Ph now

Now reboot into the newly installed system and put in the password for grub. This should then drop you into a prompt for the root password for the new system.

(Optional): It might be a good idea to automatically decrypt the encrypted /boot block device so that we can very simply just use a mount /boot command that was earalier set up in /etc/fstab. We add entries for the dmcrypt service to automatically decrypt /boot during bootup and start the dmcrypt service

hostname ~# echo "target=luks_boot" >> /etc/conf.d/dmcrypt
hostname ~# echo source=UUID=\"$(blkid -s UUID -o value /dev/nvme0n1p2)\" >> /etc/conf.d/dmcrypt
hostname ~# echo "key=/etc/luks/mnt/key/boot_os.keyfile" >> /etc/conf.d/dmcrypt
hostname ~# rc-update add dmcrypt boot
hostname ~# rc-service dmcrypt start

Conclusion

This will get gentoo booting into a shell. Modern desktop computing is however a lot more. ~~I will chronicle my system setup in a further post.~~ My gentoo desktop installation saga continues in Part-II.

OTP on the Linux command line

Dejice Jacob — Mon, 07 Mar 2022 23:33:45 GMT

Using SMS as a two-factor authentication method is quite a bad idea. Bruce Schneier agrees with NIST, saying that it should no longer have any place in a 2FA environment. The UK's National Cyber Security Centre NCSC also does not recommend this.

While this was initially a novelty, it has lately started to grate on me that each application and service has their own secure key and authentication method. They each have their own physical 2FA keys. Once a user has to carry around multiple 2FA tokens around, weariness will settle in and they will compromise on security.

To prevent this, many 2FA implementations have tried to do away with multiple 2FA devices. Most of them (for purposes other than security) have settled on the least-common-denominator 2FA method - insecure SMS. Forgetting about the security aspects (very well covered elsewhere), I am also at the mercy of being in a network coverage area. This might not be the case when travelling to a location where your network provider does not have any roaming options.

Linux's oathtool is a nifty command line tool for websites that use standard HOTP/TOTP based 2FA (RFC6238). When enabling 2FA from the "Security Options", choose to authenticate using an "authenticator application". This should pop up with a QR code or it might offer you the option of copying the private key (pKey). Most of the time the pKey is encoded using base32. The tool uses SHA-1 by default, but this can be changed using the --totp=hash-algorithm option. However, you are at the mercy of the 2FA provider. Every time you need an OTP:

$ oathtool -b --totp "My Secret Key from some service provider"
191049

Suffice it to say, please keep the pKey private and encrypted using openssl or gpg. As it can be executed on any Linux device, this does not have to be your phone (which I keep losing or damaging). TOTP is especially cool for people who travel to different time zones as the OTP is derived based on Unix Time.

Configure Mutt to work with OAuth 2.0

Dejice Jacob — Fri, 04 Mar 2022 16:53:39 GMT

My email client of choice is mutt. The keyboard short-cuts are ingrained into muscle memory. I have tried to use complex passwords to keep myself secure. While that may help, many large web service providers require the use of OAuth 2.0 for better security.

The fine defenders of the galaxy at University of Glasgow IT started pushing for better security to access email and office365 applications. If Computer Scientists do not lead the way on these things, what hope is there for the rest of digital society?

Introduction

Peter van Ormondt wrote a simplified (for dummies) guide that even I could understand. It worked first time on Outlook365 and GMail. On GMail, I can now turn off "Less Secure Apps"¹ that annoyingly keeps getting switched off, if the method is not utilised regularly.

A better understanding of how OAuth 2.0 has been implemented is explained in the OAuth 2.0 documentation found in the mutt repo. While Mutt has native OAuth2 support, it provides a hook to an external script to provide the authentication details. Conveniently, the Mutt project themselves have provided a Python script mutt_oauth2.py to authorise the user. The script keeps local state on a file which can be used to refresh the token. The mutt_oauth2.py script keeps this encrypted using gpg.

Configuration

Configure and Authorise with `mutt_oauth2.py`

Create a separate gpg user to encrypt all the OAuth2 tokens for all providers. You could just as well re-use one of your other GPG keys for this.

$ gpg --gen-key 
GnuPG needs to construct a user ID to identify your key.

Real name: My OAuth2 Token Encryption Key
Email address: token.encryptor@oauth2.me
You selected this USER-ID:
    "My OAuth2 Token Encryption Key <token.encryptor@oauth2.me>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Download and install mutt_oauth2.py

$ curl -o /any-path/mutt_oauth2.py https://gitlab.com/muttmua/mutt/-/raw/master/contrib/mutt_oauth2.py?inline=false
$ chmod u+x /any-path/mutt_oauth2.py

Replace YOUR_GPG_IDENTITY with your GPG key in mutt_oauth2.py
Our setup masquerades as the Mozilla Thunderbird e-mail client and utilizes their client-id and client-secret which is hard-coded into the client. The client secret is actually within the open-source repos of the Thunderbird client. You can also create your own credentials. See instructions for GMail. The Thunderbird client registration details as of today :
- GMail: client-id - 406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com, client-secret - kSmqreRr0qwBWJgbf5Y-PjSU
- Microsoft: client-id - 08162f7c-0fd2-4200-a84a-f25a4db0b584, client-secret - TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82
Intial authorisation for this client should be executed as: /any-path/mutt_oauth2.py /any-path/oath2_token_file --authorize. There should be a separate file for each email provider. When requested to input authorisation flow or authentication method, localhostauthcode will store the file in the same path. This is a one time operation and will be valid as long as the oauth2_token_file is available. You can delete the file and do the authorisation again if you so desire. Executing this script will provide a URL to paste into a browser. After opening the link in the browser and finishing any requisite authorisation, the script will obtain a token, encrypt it with your GPG key and store it locally in the path you have chosen.

Configure `.mutt` config

Add the following entries to the .mutt config file for OAUTH2 authentication.

set imap_authenticators = "oauthbearer:xoauth2"
set imap_oauth_refresh_command = "/any-path/mutt_oauth2.py /any-path/oath2_token_file"
set smtp_authenticators = ${imap_authenticators}
set smtp_oauth_refresh_command = ${imap_oauth_refresh_command}

xoauth2 was the experimental authentication protocol which got standardised as oauthbearer. However, it seems that while GMail seems to work with oauthbearer, Microsoft still requires xoauth2.

Roll your own Client credentials for GMail

Login to your google account, and navigate to your developer console to generate OAuth 2.0 credentials
Navigate to the "Credentials" page and click on + Create Credentials to create an OAuth client ID.

This client-ID and client-secret can then be used in the mutt_oauth2.py script.

I fear the long term consequences of cajoling users by using manipulative language such as this. It will cause a loss of credibility for experts in the long run. Regaining trust that is once lost crying "Wolf" will only happen after a period of difficult consequences for both expert and layperson. ↩