[johnisgood]

> Added nixos-init, a Rust-based bashless initialization system for systemd initrd

Rust is such a heavy dependency though, is it not? Is it worth it? Additionally, what does it add as a new project / software (disregard Rust here)? What was wrong with the previous one and/or what does this fix or add that justifies adding a heavy dependency? Seems like most of these projects are written in Rust though.

[arianvanp]

Previous version was in bash. With this change you can build a nixos image not containing bash or any shell whatsoever. Not having interpreted languages on the system at all is an effective hardening technique combined with verity store containing all your executables as it makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors.

You can read about the project here: https://github.com/NixOS/nixpkgs/issues/428908

[foxheadman]

I'm glad to see boot security prioritisation, and to see some of the fundamentals revisited, and scripts replaced with languages that contributors want to write in (NixOS leans heavy towards Rust).

As the project doc notes:

> This radical solution is only really feasible and/or interesting for appliances (i.e. non-interactive) systems.

https://pad.lassul.us/nixos-perlless-activation

> stops almost all attack vectors

Can you explain a bit more about this? Is the idea that verity protects the integrity of the nix store, and then the boot process only runs binaries that don't expose any sort of arbitrary code functionality?

I agree with https://github.com/NixOS/nixpkgs/issues/267982#issuecomment-... that the MITRE attack vector link doesn't help understanding much. Is the right idea: removing attack vectors is useful? (I agree.)

[mid-kid]

> makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors

If you have code execution - any kind - you have code execution. It really doesn't matter if a shell is available or not, you're always an open(2), write(2), and execve(2) away from creating and invoking a new executable, or just mmap(2)ing a new executable region in the current process. Yes, most exploits leverage a shell because it's convenient, so you're making it a little bit more annoying by having to first write an executable, but it really doesn't stop attacks like this.

Much more effective measures are those that prevent program takeover in the first place (SSP, ASLR), and things like W^X.