A Modern and Secure Desktop Setup

Guides
1

It took me quite a while to get to this setup so I thought I would write a guide to help others and also to discuss feedback and other setups. I have NixOS on a Tuxedo Pulse 14, a Surface Pro 6, a custom gaming PC with intel + nvidia, a ROG Ally, and a Hetzner VPS.

For those who want to jump ahead and just look at the setup, here it is. Everything is open, except for one git-crypt encrypted file where I keep sensitive info. Feel welcome to fork the repo. The setup is LUKS2 encrypted Btrfs root with a swapfile, auto unlock with TPM2, secureboot and a BIOS password.

Existing Config (Advanced)

If you have access to a second computer, have a basic config you can reuse, and have a bit of experience with nix already, I think it’s a much nicer experience to install NixOS from the other computer over the network via nixos-anywhere. This way I could prepare my config how I like it and define the partitioning with disko. It can even generate the hardware configuration and save it while deploying NixOS as described in this quick start document.

Enabling lanzaboote (secureboot module) should be temporarily removed when deploying with nixos-anywhere and then added back to be applied on the next rebuild.

If you want to use nixos-anywhere but don’t have anything usable running on the target machine - such as a Linux based OS with root or sudo access - you can start up the live installation USB on it and create a root password with passwd. Then you can start nixos-anywhere from the other computer. I only tried doing this with the target PC connected over ethernet, as I didn’t want to bother with setting up WiFi on the CLI after nixos-anywhere reboots the computer into its own environment.

It’s also possible to install your existing config with the nixos-install command on the USB Live Installer. First do the partitioning manually on the CLI or using disko following this guide. Then download your config, generate and add a hardware config if necessary. Finally if you follow the same structure as me, your install command would look something like this:

nixos-install -f <path-to-repo> -A <nixos-config-atrribute-name> --no-channel-copy --no-root-password

Start from Scratch (Simpler)

Use the graphical installer on the Live USB, pick manual partitioning:

  • boot
    • 1024 MB
    • FAT32
    • mountpoint /boot
    • boot flag
  • root
    • all the rest space
    • BtrFS with encryption
    • mountpoint /root

Other filesystems on the root partition will also work but my personal choice is BtrFS right now. Optionally, BtrFS subvolumes can be useful for adding impermanence, but that is outside then scope of this guide.

If you already have a system installed with ext4, here’s an easy to follow guide to convert to btrfs. (Optional)

During manual installation you should select disk encryption which will set it up for you. The new installer uses LUKS2 by default, however if you already have a LUKS1 encypted volume, which doesn’t work with TPM unlock, this simple guide shows you how to upgrade it to LUKS2 and switch to a more secure algorithm after the installation while you’re still on the live USB.

Click through the installer and let it do the installation, which can take a while. After rebooting into the installed system, I would start a nix-shell with nh, git and git-crypt, clone my repo to my home directory, and unlock git-crypt with a key that I exported from another machine. The repo has a top level default.nix which contains NixOS configurations for all of my computers, my home manager setup, and a devenv shell for editing the repo.

# Start a shell with needed packages
nix-shell -p nh git git-crypt

# Clone repo (e.g. from Codeberg)
git clone ssh://git@codeberg.org/<user>/<repo>
cd <repo>

# Unlock git-crypt (you need the keyfile originally used to encrypt the secrets)
git-crypt unlock <key>

Assuming that this is the first time I’m bringing up a new device, I would just create a folder for it within the hosts directory and add a default.nix and a hw.nix. I would copy the contents of the auto generated /etc/nixos/hardware-configuration.nix into this local hw.nix. For the default.nix, something like this:

{ pkgs, nixos-hardware, ... }: {
  imports = [
    ./hw.nix
    nixos-hardware.nixosModules.my-device
    ../../modules/personal.nix
  ];
  # Name
  networking.hostName = "<device-name>";
  # Swap
  swapDevices = [ { device = "/var/swapfile"; size = 10*1024; } ];  # 10 = 8 GB RAM + 2 for padding
  # DO NOT CHANGE
  system.stateVersion = "25.05";
}

The swapfile will be automatically created based on the config.

Then add a new NixOS configuration in the default module which imports this host directory, like I did for the other devices. If the device already had a working config and needs to be brought up after a fresh clean reinstall, then there is no need to recreate these 2 config files or to re-add it to the repo, just use what’s already there.

When you import a directory and not a specific file it implicitly means importing the default.nix from that directory.

After Installation

At this point we’re still missing the secure boot signing keys, so the config won’t build. Here’s a short guide to set up secureboot. First I would open a nix shell with sbctl and run the key generation command, then the build should already work.

I would remove both .nix files from /etc/nixos/* to avoid accidentally building from that and then build with nh. When building with nh, we must pass in the path to the flake or the default module with attribute name. Generally when we talk about the path to the default module, it’s the directory that contains the default.nix and not the file itself.

nh os switch -f <path> <attribute-name>

# For example I usually navigate to my nixos-configs repo and invoke this for my Tuxedo laptop:
nh os switch -f . tuxedo

Enrolling the secureboot key was a different process for all my machines. On the surface I just ran the enroll command and it just worked after that. On the tower I had to turn ON the Windows 10 WHQL settings in BIOS, switch a newly appeared setting from CSM to UEFI and then put secureboot in a setup state, then reboot and run the enroll command. On the Tuxedo I had to put secureboot into “custom” mode, disable auto enroll of factory keys, and then put it in setup mode.

After enabling secureboot I put a BIOS password on both machines. On some machines it might be relatively easy to reset the BIOS settings and therefore disable secure boot even with a BIOS password set, but at least that will trip the TPM and prevent auto-unlocking of the root partition.

After enrolling the keys and enabling secureboot, make sure to reboot and verify that it works according to the guide.

Finally I enrolled the disk decryption key in the TPM chip. To be secure, make sure to also add PCR15 with value 0 and add tpm2-measure-pcr=yes to crypttabExtraOpts.

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs="0+2+3+7+8+12+13+14+15:sha256=0000000000000000000000000000000000000000000000000000000000000000" /dev/<root-partition>

# Modify HW config
boot.initrd.luks.devices."luks-<...>" = {
  device = "/dev/disk/by-uuid/<...>";
  crypttabExtraOpts = [ "tpm2-device=auto" "tpm2-measure-pcr=yes" ];
};

The cryptenroll command and another command to find the name of your encrypted partition are both in my README.

At this point, you should be able to reboot with secureboot enabled and only have to enter your login password, not the encryption password. Depending on your hardware, this setup is fairly secure. As long as your nix configuration doesn’t install malicious software. If an attacker tampers with your unencrypted boot, secureboot will fail, and if they disable secureboot or load a live USB the TPM won’t decrypt your root partition, so they won’t be able to access your data. If they backup and replace your encrypted root partition with an unencrypted malicious setup and then try to unlock the backup with the TPM, it will fail the PCR 15 check thanks to binding it to value 0 and measuring the unlocked system in it after unlocking it.

If they steal your laptop, modify your boot partition, get past your BIOS password, disable secure boot, and return your laptop without you noticing, then you unknowingly turn it on, not notice that secure boot is off, then enter the encryption key to unlock your drive, then they could gain access to your data. Or using cold boot attack…

After you confirmed that everything works, nh clean all can free up some space and make your boot menu cleaner by erasing old boot generations and unused packages.

21 Likes
2

I’ve had many a rant about git-crypt in NixOS land, but it sounds like you’ve thought this through. Do you consider the fact that your secrets end up with o+rwx unproblematic?

Is it worth at least caveating for people following along that you shouldn’t use remote builds/caches with this kind of setup? That you should not store secrets that shouldn’t cross the UID barrier with git-crypt?

I still think agenix/sops-nix/scalpel should always be preferred over git-crypt for secrets in NixOS configurations…

1 Like
3

Hey, thanks for the feedback. What you said makes a lot of sense, and I agree, git crypt should not be used for real secrets. In this case I just used it for privacy for my email address, name, username, etc since I wouldn’t want necessarily everyone who looks at my repo to see which email provider I use, though it was more of an exercise, since my name and email are visible here or on GitHub anyway.

It’s a good point to avoid pushing to a public cache when your build contains plain text secrets and if there’s someone else using your system they could potentially find it in the nix store, though to be fair the latter scenario sounds a bit unlikely.

The options you linked here definitely look like a better alternative for servers and similar but you can’t use them for everything, eg the host name. I don’t use SSH keys that much on my machines apart from GitHub and I’m not sure if I care enough about that to include it in my build.

I also thought about using Bitwarden CLI for secrets since I use it anyway for my passwords. That way the secrets don’t get into the builds at all, but I imagine there can be downsides to that as well. It would at least make a lot of sense for my email configuration, since it’s better for those to always be up to date, it doesn’t make sense to roll it back.

1 Like
4

You absolutely can, though it takes some custom module writing and runtime evaluation here and there. Especially scalpel is specifically designed to overcome those limitations.

That said, if the information is just confidential rather than secret, yep, git-crypt makes more sense!

You can alternatively use gpg or age keys. But yeah, I appreciate that there’s a population of users for whom any encryption is a significant barrier to entry. I’ve previously talked about perhaps setting up a secret management standard that doesn’t require it, but just formalizes how secrets are stored outside the nix store.

To be clear, we’re still talking about email addresses and other sensitive information, rather than encryption keys, passwords and other secrets in the security sense of the word here?

The home-manager modules and such simply are not designed to take that information from anything but plaintext NixOS modules, because their authors don’t consider that information confidential.

Git-crypt is an ok solution for this. The other alternative I prefer is to keep a separate flake in a private (perhaps even offline) repo that you depend on in your public flake which just holds that data - no encryption required. You can also just choose not to make your repositories public in the first place.

The “correct” solution would be to write your own modules that do treat the data confidentially, so that users can supply it any way they like (such as through bitwarden at runtime), and perhaps upstream it as an alternative.

5

In the last case I meant using Bitwarden in the email configuration password command instead of adding the password to the build in any form.

6

Also, do you know if it is possible to make the home manager email/calendar system work with the gnome apps?

7

I learned about TPM2 :+1: Thanks for the guide! Quite useful to have a kind of checklist of all elements that go into a secure desktop.

1 Like
8

Never experimented with that, sorry. There’s probably a way, but may not be implemented.

1 Like
9

I’m going to also setup secure boot and tpm auto unlock luks. In the hacker scenario you described, should I do the following:

If nixos asks me to enter the luks password, I should reboot and check that secure boot is on. If it was turned off, then I should reinstall the boot partition?

10

If it’s off, someone tampered with your device. You’d wipe the boot partition, take out the hard drive, copy your data somewhere else and replace the device.

Malware in the firmware of your motherboard is a real possibility at that point, since the attacker was both motivated enough to and clearly capable of bypassing any protections the firmware had in place (and that firmware is notoriously awful at security, so you should expect it to have folded like paper).

11

since the attacker was both motivated enough to and clearly capable of bypassing any protections the firmware had in place

I guess this is very unlikely, but if it does happen, I should take serious precautions before entering any passwords.

Does having easily modifyable firmware affect security? I have a Chromebook which has MrChromebox coreboot firmware and anyone can modify coreboot, build it, and then flash firmware on my Chromebook externally. I’m guessing that doing this would stop the TPM from auto-unlocking the drive, but I’m not sure. I think that will happen even when I upgrade the firmware.

12

The linked repository seems to have been taken offline. Now this guide is not really usable anymore. Any alternatives?

1 Like
13

I updated the link just now. Also a lot of info is outdated as the new installer iso uses LUKS2 by default. Ideally I would also do the formatting with disko but I don’t have enough time to figure that out :slight_smile: I hope it helps anyway

Edit: LUKS2 instead of TPM2

1 Like
14

Wait what? Did I miss something in the article about a custom ISO or something? Because the standard NixOS ISO certainly does not use TPM2 by default for anything.

15

I’m pretty sure it does, from 24.05 at least
I just installed it on my new laptop a couple weeks ago.

Edit: sorry I meant LUKS2

16

I just successfully installed a new NixOS machine with an encrypted root (yes, the latest installer does LUKS2) and followed the latest quickstart guide in order to setup secure boot. Enabling the UEFI setup mode on my new Asus laptop worked the same as described for Thinkpads.

Next up, trying to see if I can enable TPM LUKS unlocking. (For me, this is not a must, but nice-to-have).

UPDATE: Setting up TPM Unlocking as described here worked flawlessly. Awesome.

1 Like
17

I probably need to note that TPM2 unlocking is dangerous and difficult to do correctly. Not impossible, but difficult (and I’ve yet to see it done correctly in any online guide with NixOS). For instance with this guide, an attacker could decrypt the hard drive if they stole the laptop. If the attacker took out the hard drive, backed up its (ciphertext) contents, and then replaced the root partition with a malicious one for which they know the passphrase, the system would happily boot the unmodified ESP, which would then boot the malicious root partition, and they’d be running an OS that they control. Then they can plug in their ciphertext backup and use the TPM2 to decrypt it because secure boot was still honored and therefore PCRS 0,1,2,3,7 are all still valid.

And there are a variety of different ways to attack at this angle that I’ve explored and demonstrated. The way to defend against this is with something like systemd-pcrphase or systemd-pcrlock, where you guarantee that the TPM2 state changes before handing control over to potentially compromised code. But lanzaboote isn’t set up for those specifically yet, so I use a slightly different mechanism in my system.

I also bind my disk to PCR 15:sha256=00000... (meaning PCR 15 must have no measurements in order to decrypt), and add crypttabExtraOpts = [ "tpm2-measure-pcr=yes" ]; (meaning that it will measure the decrypted LUKS volume key into PCR 15). So at first, PCR 15 is zero, and stage 1 will decrypt a disk. The volume key is then measured into PCR 15, so now I know that my real disk cannot be decrypted anymore. Only after this point is control handed over to a possibly malicious stage 2. But you have to be absolutely sure that this PCR 15 measurement will definitely take place before handing over control. For most systems this is as simple as ensuring the root device is /dev/mapper/<name> rather than /dev/disk/by-uuid/asdf or anything else, because the mapper path imposes the necessary systemd ordering.

Of course it’d be nice to have proper stage 2 verification to avoid all of this, but that’s significantly more difficult, and it doesn’t help in the case where you want a vendor-signed OS, so these TPM2 state changes are still necessary in the grand scheme.

EDIT: Another one of my systems does this nonsense, which only auto-unlocks a zvol with SSH host keys and Tailscale state on it and requires a passphrase (as pin for TPM2) for the root fs. That way I can log in remotely during stage 1 using Tailscale+SSH, know that secure boot was honored because the system was able to decrypt those keys, and manually enter a TPM2 pin that should only work for my actual root fs.

9 Likes
18

@ElvishJerricco Thank you for the info, that’s really good to know! Would you be willing to provide detailed step by step instructions for settings this up correctly?

19

@saldor
After recent updates the TPM2 auto unlock stopped working for me, actually. Does it work for you? Did you have to add the crypttabExtraOpts = [ "tpm2-device=auto" ]; to make it work?

20

FWIW, in my case the threat model I’m protecting against is just a drive failure (which has happened to me in the past), so I wouldn’t have to worry about sending it for shredding or warranty exchange. So from that perspective, TPM2 unlocking is a no-brainer and serves the intended purpose.

For those worried about physical theft though, yes it defeats the purpose, to a large extent.