disko is more than a package so just adding it into nixpkgs won’t be as straight forward as other things. also we kinda abuse the type system a little bit so up-streaming everything could be difficult. But yeah ideally we would like disko more integrated into the overall NixOS installation/update process but currently I see no easy way to do that without some changes
I wish there was a bit more information here about exactly how to run the relevant nix commands necessary to build this. Putting the contents of the code block verbatim into a flake.nix file and running nix build .#sd-image doesn’t work, and I don’t feel like reading a bunch of incomplete nix flakes documentation to figure out what step I’m doing wrong right now. The linked nixos-generators program, which I’ve never seen before, doesn’t seem to expect to use flakes, and it also seems like it would be a pain to make the information in this post conform with how that expects to be run either.
Obviously a random person writing a blog post isn’t obliged to write a blog post I personally would find helpful; but this does strike me as an example of the annoying tendency in the nixos world for documentation and guides about doing anything out of the ordinary to be broken and require a bunch of experimentation in order to get to work.
Wow! I’ve been slowly working my way towards using NixOS as my daily driver, and this article feels like it was written just for me. It’s a Christmas miracle! :D
I was just thinking of trying out NixOS with a new bare metal server. My goal is to not touch the CLI at all and have all ‘configuration state’ in a git repo. NixOS isn’t strictly required for that, granted, but I’ve been meaning to try it out. My normal server provider has web KVM with remote iso mounting so this should work great to bootstrap.
EDIT: Question - does anyone know if you could run the nix build step on the remote machine, potentially eliminating the network copy of the whole result system closure?
sure, as that is the “intended” use you just have to run: nixos-install --flake github:blake/my-nixos-flakes#mysystem which would download your system as a flake from github and install it right there. I think you could also give it a local path as a flake, but unsure what the exact syntax would be maybe $path#$system is enough or something with file://
Currently I’m also working on nixos-remote which should allow an easy way to install systems from flakes. Right now it only supports local building and copy closure as this is less memory intensive on the target system. It’s also quite under-documented (as disko is also right now)
You probably don’t want disk encryption on root with Nix. Given the statelessness of the design, anyone should by able to pull your config—which most are putting up on a code forge—and create the same machine. You’re effectively leaving “HH” at the end of your message for the Allies to decrypt, but for your disk. A coworker and I decided a better setup would be creating a subset(s) of the disk to be encrypted with parts that are actually mutated, like the home directory, shared media, var (which in my case meant setting up an a ZFS mount with filesystem encryption and a separate partition to encrypt swap/support hibernate).
Modern encryption systems should be robust against known-plaintext attacks. Different people encrypting disks with the same (or substantially similar) /nix/ paths should have very different random-looking ciphertext, and if they don’t that’s a serious security vulnerability with the encryption algorithm. Of course this requires that they have different encryption keys which means that the encryption keys themselves can’t be managed in a completely stateless way with nix, but that’s necessary regardless.
There’s value in encrypting absolutely everything on a disk as a matter of course, regardless of whether or not it’s easily-regenerateable data like /nix store paths from a publicly-available nix configuration. And it’s not like people are obliged to make their configuration.nix files publicly available - they might be modified to have some custom, confidential nix packages or other nix configuration in any case!
The encryption does more than make things unreadable. It also prevents anyone from modifying the contents of a machine without a login. Then secure boot ties it all together with “you need to authenticate in order to unlock the filesystem” and nothing can be modified before that step.
That’s something I hadn’t thought of. I was thinking more along the threat vector of the device getting stolen and forgetting to wipe the drives when I was done with it, not someone modifying it to give it back to me.
But we were talking about NixOS specifically here. That said, are there any mainstream distributions that do initrd signing and verification out of the box?
TIL about disko: my least favorite part of installing a new system is wrangling disks and partitions, it looks like a game changer
Looks like it’s not in nixpkgs; that seems like it should be fixed.
disko is more than a package so just adding it into nixpkgs won’t be as straight forward as other things. also we kinda abuse the type system a little bit so up-streaming everything could be difficult. But yeah ideally we would like disko more integrated into the overall NixOS installation/update process but currently I see no easy way to do that without some changes
It would be great to get it upstreamed once it’s ready, until then it looks easy to use as a flake
I wish there was a bit more information here about exactly how to run the relevant nix commands necessary to build this. Putting the contents of the code block verbatim into a
flake.nixfile and runningnix build .#sd-imagedoesn’t work, and I don’t feel like reading a bunch of incomplete nix flakes documentation to figure out what step I’m doing wrong right now. The linkednixos-generatorsprogram, which I’ve never seen before, doesn’t seem to expect to use flakes, and it also seems like it would be a pain to make the information in this post conform with how that expects to be run either.Obviously a random person writing a blog post isn’t obliged to write a blog post I personally would find helpful; but this does strike me as an example of the annoying tendency in the nixos world for documentation and guides about doing anything out of the ordinary to be broken and require a bunch of experimentation in order to get to work.
Wow! I’ve been slowly working my way towards using NixOS as my daily driver, and this article feels like it was written just for me. It’s a Christmas miracle! :D
I was just thinking of trying out NixOS with a new bare metal server. My goal is to not touch the CLI at all and have all ‘configuration state’ in a git repo. NixOS isn’t strictly required for that, granted, but I’ve been meaning to try it out. My normal server provider has web KVM with remote iso mounting so this should work great to bootstrap.
EDIT: Question - does anyone know if you could run the
nix buildstep on the remote machine, potentially eliminating the network copy of the wholeresultsystem closure?sure, as that is the “intended” use you just have to run:
nixos-install --flake github:blake/my-nixos-flakes#mysystemwhich would download your system as a flake from github and install it right there. I think you could also give it a local path as a flake, but unsure what the exact syntax would be maybe$path#$systemis enough or something withfile://Currently I’m also working on nixos-remote which should allow an easy way to install systems from flakes. Right now it only supports local building and copy closure as this is less memory intensive on the target system. It’s also quite under-documented (as disko is also right now)
The local syntax for nixosConfigurations.hostname is
nixos-install --flake <flake-dir>/and you can # that. it has to be a git repo.You probably don’t want disk encryption on root with Nix. Given the statelessness of the design, anyone should by able to pull your config—which most are putting up on a code forge—and create the same machine. You’re effectively leaving “HH” at the end of your message for the Allies to decrypt, but for your disk. A coworker and I decided a better setup would be creating a subset(s) of the disk to be encrypted with parts that are actually mutated, like the home directory, shared media, var (which in my case meant setting up an a ZFS mount with filesystem encryption and a separate partition to encrypt swap/support hibernate).
Modern encryption systems should be robust against known-plaintext attacks. Different people encrypting disks with the same (or substantially similar)
/nix/paths should have very different random-looking ciphertext, and if they don’t that’s a serious security vulnerability with the encryption algorithm. Of course this requires that they have different encryption keys which means that the encryption keys themselves can’t be managed in a completely stateless way with nix, but that’s necessary regardless.There’s value in encrypting absolutely everything on a disk as a matter of course, regardless of whether or not it’s easily-regenerateable data like
/nixstore paths from a publicly-available nix configuration. And it’s not like people are obliged to make their configuration.nix files publicly available - they might be modified to have some custom, confidential nix packages or other nix configuration in any case!The encryption does more than make things unreadable. It also prevents anyone from modifying the contents of a machine without a login. Then secure boot ties it all together with “you need to authenticate in order to unlock the filesystem” and nothing can be modified before that step.
That’s something I hadn’t thought of. I was thinking more along the threat vector of the device getting stolen and forgetting to wipe the drives when I was done with it, not someone modifying it to give it back to me.
That’s fair, in the end it depends on what are credible threats and for most people it’s just theft.
The initrd is not signed, so an adversary could easily add a keylogger. It primarily protects agains theft.
It depends on the distro. It often isn’t, but for proper secure boot it should be. https://haavard.name/2022/06/22/full-uefi-secure-boot-on-fedora-using-signed-initrd-and-systemd-boot/
But we were talking about NixOS specifically here. That said, are there any mainstream distributions that do initrd signing and verification out of the box?
Not that I know of, but it’s a matter of time now. Secure boot is just not complete without it.