Srijan Choudhary, all posts tagged: security

Encrypting an existing Linux system's root partition

Srijan Choudhary — Wed, 22 Feb 2023 19:45:00 +0000

Introduction

I have an Arch Linux system with an unencrypted root partition that I wanted to encrypt. I've documented the steps I followed to achieve this here.

I selected the "LUKS on a partition" option from here. I don't have an LVM setup on this system and didn't need to encrypt the boot partition.

The first step was to have a backup so that if something failed, I could at least recover my critical files. I don't have filesystem-level backups configured, so I used kopia to back up my home folder. Details on this might be in a future blog post.

Process

1. To begin, I set up a USB flash installation medium so that I could boot into a live environment to perform the actual actions. Since I needed to encrypt the root partition, this could not be performed from inside the system running off that partition.

2. After booting into the live environment using the above USB medium, I first shrank the existing filesystem by 32MiB to make space for the LUKS encryption header, which is always stored at the beginning of the device. My filesystem size is exactly 500GiB, so I set the new size to 511968M.

# echo "Check the filesystem"
# e2fsck -f /dev/nvme0n1p7

# echo "Resize"
# resize2fs -p /dev/nvme0n1p7 511968M

3. Now, I encrypted it using the default cipher. This took 37 minutes on my 500GiB partition, which was about 55% full.

# cryptsetup reencrypt --encrypt --reduce-device-size 16M /dev/nvme0n1p7

WARNING!

========

This will overwrite data on LUKS2-temp-12345678-9012-3456-7890-123456789012.new irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for LUKS2-temp-12345678-9012-3456-7890-123456789012.new: 
Verify passphrase:

4. Next, I extended the original ext4 file system to occupy all available space again on the now encrypted partition:

# cryptsetup open /dev/nvme0n1p7 root
Enter passphrase for /dev/nvme0n1p7: 

# resize2fs /dev/mapper/root

5. Now, I mounted the filesystem and chrooted into it:

# mount /dev/mapper/root /mnt
# mount /dev/nvme0n1p1 /mnt/boot
# arch-chroot /mnt

6. Since I have a systemd-based initramfs, I added keyboard, sd-vconsole, and sd-encrypt hooks in the HOOKS section of /etc/mkinitcpio.conf:

HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

/etc/mkinitcpio.conf

7. Next, I regenerated the initramfs ( -P regenerates it for all presets ):

# mkinitcpio -P

8. Next, I configured the boot loader by adding to kernel parameters:

rd.luks.name==root root=/dev/mapper/root

I found the device UUID using: sudo blkid -s UUID -o value /dev/nvme0n1p7. Surprisingly (for me), the UUID had changed after encrypting the partition.

My final bootloader conf file looked like this:

title    Arch Linux
linux    /vmlinuz-linux
initrd   /amd-ucode.img
initrd   /initramfs-linux.img
options  rd.luks.name=1df8ea89-4274-4ef9-a670-76c13e612901=root root=/dev/mapper/root rw

/boot/loader/entries/arch.conf

9. Lastly, I updated /etc/fstab:

/dev/mapper/root  /  ext4  rw,relatime  0 1

/etc/fstab

10. All done. To test it out, I logged out of the chroot environment and rebooted the system.

It asked me for the disk encryption password. After entering the password selected in step 3, the system booted up as usual, and everything looked to be working.

Final Thoughts

This was surprisingly easy to do and did not take much time. The ArchWiki was helpful, even if the information was spread over multiple pages/sections. Taking a backup before starting also made me feel safe about the process.

I did not like the design of the decryption password prompt at bootup. Maybe there's a way to customize it to look better. Update: I found a way. Details here.

Download a file securely from GCS on an untrusted system

Srijan Choudhary — Sun, 27 Nov 2022 19:30:00 +0000

The Problem

We publish some of our build artifacts to Google Cloud Storage, and users need to download these to the target installation system. But, this target system is not always trusted and can have shared local users, so we don't want to store long-lived credentials.

As a user, I can download the artifact on my (secure) laptop and transfer it to the target system. But, the artifact can be large (several GBs). So, downloading and uploading again makes it cumbersome and slow.

Option 1: use gcloud CLI on the target system

$ gcloud storage cp gs://$BUCKET/$FILE ./

This has two problems:

The user must install (and maybe update) gcloud CLI on the target system.
The user needs to store their credentials on the target system. These credentials have full access to whatever resources the user has. So, it's a huge security risk, especially if we don't trust the target system.

To mitigate (2), the user can log out of gcloud CLI after downloading. But, this is a manual step they might miss.

Option 2: use gcloud CLI with a service account

This is a variation of the above solution - we log in using a service account instead of the user account. This service account can have restricted access to only the resources needed.

$ gcloud iam service-accounts create $SA_NAME \
    --description="Service Account for downloading artifacts"
$ gsutil iam ch \
    serviceAccount:$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com:roles/storage.objectViewer \
    gs://$BUCKET

This partially mitigates problem (2) above. If the user forgets to log out of gcloud CLI, the damage will be restricted to the resources accessible by the service account.

Option 3: Short-lived access token

Gcloud CLI supports creating short-lived credentials for the end-user account or any service account.

This credential can be used to download the artifact using wget with an authorization header - no need to install gcloud CLI.

Here's a small script that asks for the auth token as input, parses various GCS bucket URL formats, and downloads the requested artifact directly using wget:

#!/bin/bash
# Download artifact from GCS bucket

set -e

echo -e "====> Run \`gcloud auth print-access-token\` on a system where you've setup gcloud to get access token\n"
read -r -p "Enter access token: " StorageAccessToken
read -r -p "Enter GCS artifact URL: " ArtifactURL

if [[ "${ArtifactURL:0:33}" == "https://console.cloud.google.com/" ]]; then
    BucketAndFile="${ArtifactURL#*https://console.cloud.google.com/storage/browser/_details/}"
elif [[ "${ArtifactURL:0:33}" == "https://storage.cloud.google.com/" ]]; then
    BucketAndFile="${ArtifactURL#*https://storage.cloud.google.com/}"
elif [[ "${ArtifactURL:0:5}" == "gs://" ]]; then
    BucketAndFile="${ArtifactURL#*gs://}"
else
    echo "Invalid GCS artifact URL"
    exit 1
fi

StorageBucket="${BucketAndFile%%/*}"
StorageFile="${BucketAndFile#*/}"
StorageFileEscaped=$(echo "${StorageFile}" | sed 's/\//%2F/g')
OutputFileName="${StorageFile##*/}"

echo -e "\n====> Downloading gs://${StorageBucket}/${StorageFile} to ${OutputFileName}\n"

wget -O "${OutputFileName}" --header="Authorization: Bearer ${StorageAccessToken}" \
    "https://storage.googleapis.com/storage/v1/b/${StorageBucket}/o/${StorageFileEscaped}?alt=media"

Option 4: Signed URLs

Google Cloud Storage also supports signed URLs - which give time-limited access to a specific Cloud Storage resource. Anyone possessing the signed URL can use it while it's active without any further credentials. This fits our use case brilliantly.

To do this, first we need to give ourselves the iam.serviceAccountTokenCreator role so that we can impersonate a service account.

$ gcloud iam service-accounts add-iam-policy-binding \
	$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com \
    --member=$MY_EMAIL \
    --role=roles/iam.serviceAccountTokenCreator

Then, we can generate a signed URL:

$ gcloud config set auth/impersonate_service_account \
    $SA_NAME@$PROJECT_ID.iam.gserviceaccount.com

$ gsutil signurl -u -r $REGION -d 10m gs://$BUCKET/$FILE

$ gcloud config unset auth/impersonate_service_account

And we can use wget to download the artifact from this URL without any further authentication.