Default security settings

Development Security
1

I installed lynis and run lynis audit system --quick with quite plain and basic configuration.nix.
The overall score was a bit too low for my personal taste. Some of the suggestions that lynis gives, are probably meaningless on a single user case, or otherwise on a category of either a bit naive or overlapping to some other existing one.

But then, there were a whole set of suggestions that were much more important. Here are some findings.

The hardened section describes, how we can add a set of security settings in one go and the link shows the underlying single configuration settings. This covers some of the lynis suggestions.

The closest topic on discourse is cis benchmark.

Lynis coverage shortly

Memory and processes; users, groups and authentication; shells; file systems; usb devices; storage; nfs; name services; ports and packages; networking; printers and spools; software on several separate categories; ssh; logging and files; insecure services; banners; scheduled tasks; accounting; time and sync; cryptography; virtualisation; containers; kernel hardening etc.

For full list, please do run the audit.

Findings, suggestions, questions about manual

On manual the text on hardened says:

It also disables the User Namespaces feature of the kernel, which stops Nix from being able to build anything (this particular setting can be overriden via security.allowUserNamespaces ).

Can this lead to a kind of lock-down? That is, if nixos-rebuild switch needs to compile something, and one doesn’t remember to override that usenamespace setting, does this mean that the NixOs is lock-down to that particular setup and re-installation is the only option after this one? Or does the building refer to installing any packages?
I’m asking, since this is how I get the manual.

  1. Could manual section 39.7 be extended a bit on what it does? Or maybe add an example on how to do it in a way that doesn’t mean troubles to the user? Or is the re-boot and using older generation of configuration.nix the way to go here if in trouble? Maybe a short note about this. (If tweaking settings, I wouldn’t like to re-boot, unless necessary, as it takes long time.)

  2. Maybe add some notes on how to enable, configure and use usbguard. Links to wiki’s or some places containing examples?

  3. Maybe add some notes on how to enable, configure and use audit and auditd options. Links to wiki’s or some places containing examples?

  4. Further, the manual could say something about, how to check or audit the security or give some hints what tools can be used to do such things.

Findings, suggestions, questions about hardening settings

  1. It would be really nice if there were either sections of settings that could be turned on separately, or a kind of layers of progressively harder settings like select your paranoidity level. This probably requires more development work and is not just a question of updating the manual, if made easy to use for users.
    Anyhow, manual could already reflect something like this and show: “if you want to take the first step towards hardering, set the following.” “If still feeling unshaky, these are the next steps…” etc.

  2. Default settings for ssh? Lynis almost screamed on the ssh settings.

  3. Password quality and in general the password management default settings. Even though this is also a convenience matter for personal users, the defaults could be bit more towards generally accepted good conventions and there could be more options that users can set (and instructions).

  4. There were several other things that could be done, and maybe set on as default. Maybe change the defaults to a bit more secure and add options that allow less secure settings? Inclugind the above things. Anyhow, lot’s of work. Maybe a plan or road-map for some of the things to-do?

3 Likes
2

Thanks for pursuing this!

Lynis

In addition to addressing the genuine issues, there are a couple things we could do to reduce the noise:

  1. There are probably still some false alerts due to global file systems not existing as expected in Nixos. Upstream has historically been receptive to creating edge cases to handle these situations but I don’t think anyone has worked on this lately.
  2. We could also consider developing a nixos custom lynis profile to filter out irrelevant tests.

Hardened Profile Usage

I don’t believe there’s any threat of breaking your nixos installation with the hardened profile.

For one thing it’s somewhat difficult to break a nixos installation in general because you can always* roll back to a previous generation or modify your configuration.nix and rebuild. You usually wont need to reboot you can just nixos-rebuild switch --rollback. (*This statement may not be applicable if your messing with the boot process. I recently did manage to break the initrd on a system and was unable to recover.)

But if you encounter this particular issue the nixos-rebuild switch will fail and your system wont be rebuilt so a broken system will not result.

To clarify on “building vs installing”, with user namespaces disabled you’ll be able to install packages from binary caches but will be unable to build from source. Unless you’ve set up a build server and cache to build your particular packages this is unlikely to be practical, in part because the hardened profile itself invalidates a number of packages in the main nixpkgs cache.

Progressive Hardening Documenation

As for your suggestions on improving the hardened documentation and a progressive hardening strategy – I believe the current strategy of the hardened profile maintainers is to stabilize various hardening measures in the hardened profile so they can eventually be integrated into the default profile. The hardened profile itself is a compromise the devs have reached between usability and security. Perhaps adding notes to the hardened documentation of ways to tilt this balance toward usability or security would be good. For example:

To make the hardened profile more usable, set:

  • security.allowUserNamespaces = true so that you can build packages from source
  • security.lockKernelModules = false so that packages and services can dynamically load kernel modules
  • security.hideProcessInformation = false to expose process information to non-root users

To make the hardened profile more secure, set:

  • environment.memoryAllocator.provider = "graphene-hardened"; to enable more aggressive memory corruption mitigation

Another advantage of this documentation is that it would serve as a working document on the direction of the hardened profile itself – the first list are the things that need to be more usable in order to be removed from the list and the second list are things that need to be more usable so they can be moved into the hardened profile.

2 Likes