- Oct 3, 2022
- 557
Hi Everyone,
The last few weeks I have been experimenting with NixOS. Nix & NixOS | Declarative builds and deployments
It's main strength to me is that it offers package upgrade Batch integrity. The entire batch of packages being upgraded will fail if the stream is tampered with. It is better than just offering to check each individual package for validity; batch checks means nobody can deliberately insert malicious dual purpose app or a package with chosen vulnerabilities into your upgrade batch.
It has one single 'configuration.nix' configuration file where you specify everything, configure everything for your installation or upgrade. So there are no multiple .conf files to manage. And it makes for a very simple fresh install process, you just install the OS the first time, copy over your own configuration file and rebuild.
And it doesn't follow standard the standard Linux directory layout. There is still an /etc directory, but all of the normal editable '.conf' configuration files are links to the read-only directory /nix/store. And individual packages are also stored in that read only mounted volume. So there is some security via obscurity - normal Linux scripted attacks won't work.
NixOS has it's own way of specifying configurations, and it is with pre-defined 'options' which you can add to your 'configuration.nix' file. The options range from a single xxx.enable=yes to xxx.parameter= "..." . There is an option where you can add to the built in firewall rules. You have to find out available options here: https://nixos.org/manual/nixos/stable/options The fact that there exists 'options' for you to specify, means that things have been thought out, planned, and tested. And it is a good thing.
From browsing the available options, I see that NixOS has a focus on development teams, because there are option settings for collaboration servers of all sorts.
You also specify what packages to include in your 'configuration.nix' . You can find out what packages are available here: NixOS Search
Once you have finished specifying your changes in your 'configuration.nix', you do a build with the command 'nixos-rebuild switch'. It will reconfigure itself; download whatever new packages you added, and then you reboot.
NixOS offers rollback capability due to it keeping versions of each change. The boot menu just grows with each rebuild. When you wish to get rid of the old versions, there is a garbage collection command.
NixOS also has built in virtualization capabilities, just like Window's HyperV. It is intended for developers to build and test their software. I have not explored this facet.
NixOS also support apparmor, the mandatory access control at each program level. Since this distro uses a non-standard folder layout, and changeable guid directory names to package binaries, I would imagine it's usefulness would be limited.
-------------------------------------
Now, for the short comings. There is a command 'nix-env' and you can install any package interactively with 'nix-env -i myDesiredPackage' like in any normal distro. This command, however is executable by the whole world because of it's file permissions. You cannot restrict it via sudo. The work around is to manually re-mount the volume /nix/store as read-write; then change that permission by doing 'sudo chmod o-x ... ' and then re-mount the volume as read-only. And you have to remember to manually do that after each rebuild. It is hard to automate this because the /nix/store uses changeable guid folder names below. Someone explained away this configuration design fault to me as due to the distro being 'libre software', and they don't want to restrict the user's freedom. What security baloney.
An attacker that has made it onto an account can also use the command 'curl' to install software. This command is built in also and is also world executable. You have to find the current build's guid directory and change it's permission after every build.
The main thing I cannot live with is that the distro needs to be online when you re-build. Some changes do not require one to be online, but I find that to be unpredictable.And worse, is that the default install comes with very little software. Programs like Gnome Backup and Libre Office do not come standard. You can't do a restore from backup without Gnome Backup. So you Have to go online at least once, when your configuration is at it's weakest state - no needed firewall rules in place; un-needed daemons are not hardened; and so on. The best way to install an OS is to install it offline, configure and harden it, then expose it to the world.
So if you can live with the short comings I've identified, or think nothing of it, you are welcome to experiment and make additional improvements. I will be posting my current work-in-progress 'configuration.nix' file in the next post to this thread.
The last few weeks I have been experimenting with NixOS. Nix & NixOS | Declarative builds and deployments
It's main strength to me is that it offers package upgrade Batch integrity. The entire batch of packages being upgraded will fail if the stream is tampered with. It is better than just offering to check each individual package for validity; batch checks means nobody can deliberately insert malicious dual purpose app or a package with chosen vulnerabilities into your upgrade batch.
It has one single 'configuration.nix' configuration file where you specify everything, configure everything for your installation or upgrade. So there are no multiple .conf files to manage. And it makes for a very simple fresh install process, you just install the OS the first time, copy over your own configuration file and rebuild.
And it doesn't follow standard the standard Linux directory layout. There is still an /etc directory, but all of the normal editable '.conf' configuration files are links to the read-only directory /nix/store. And individual packages are also stored in that read only mounted volume. So there is some security via obscurity - normal Linux scripted attacks won't work.
NixOS has it's own way of specifying configurations, and it is with pre-defined 'options' which you can add to your 'configuration.nix' file. The options range from a single xxx.enable=yes to xxx.parameter= "..." . There is an option where you can add to the built in firewall rules. You have to find out available options here: https://nixos.org/manual/nixos/stable/options The fact that there exists 'options' for you to specify, means that things have been thought out, planned, and tested. And it is a good thing.
From browsing the available options, I see that NixOS has a focus on development teams, because there are option settings for collaboration servers of all sorts.
You also specify what packages to include in your 'configuration.nix' . You can find out what packages are available here: NixOS Search
Once you have finished specifying your changes in your 'configuration.nix', you do a build with the command 'nixos-rebuild switch'. It will reconfigure itself; download whatever new packages you added, and then you reboot.
NixOS offers rollback capability due to it keeping versions of each change. The boot menu just grows with each rebuild. When you wish to get rid of the old versions, there is a garbage collection command.
NixOS also has built in virtualization capabilities, just like Window's HyperV. It is intended for developers to build and test their software. I have not explored this facet.
NixOS also support apparmor, the mandatory access control at each program level. Since this distro uses a non-standard folder layout, and changeable guid directory names to package binaries, I would imagine it's usefulness would be limited.
-------------------------------------
Now, for the short comings. There is a command 'nix-env' and you can install any package interactively with 'nix-env -i myDesiredPackage' like in any normal distro. This command, however is executable by the whole world because of it's file permissions. You cannot restrict it via sudo. The work around is to manually re-mount the volume /nix/store as read-write; then change that permission by doing 'sudo chmod o-x ... ' and then re-mount the volume as read-only. And you have to remember to manually do that after each rebuild. It is hard to automate this because the /nix/store uses changeable guid folder names below. Someone explained away this configuration design fault to me as due to the distro being 'libre software', and they don't want to restrict the user's freedom. What security baloney.
An attacker that has made it onto an account can also use the command 'curl' to install software. This command is built in also and is also world executable. You have to find the current build's guid directory and change it's permission after every build.
The main thing I cannot live with is that the distro needs to be online when you re-build. Some changes do not require one to be online, but I find that to be unpredictable.And worse, is that the default install comes with very little software. Programs like Gnome Backup and Libre Office do not come standard. You can't do a restore from backup without Gnome Backup. So you Have to go online at least once, when your configuration is at it's weakest state - no needed firewall rules in place; un-needed daemons are not hardened; and so on. The best way to install an OS is to install it offline, configure and harden it, then expose it to the world.
So if you can live with the short comings I've identified, or think nothing of it, you are welcome to experiment and make additional improvements. I will be posting my current work-in-progress 'configuration.nix' file in the next post to this thread.
Last edited: