Proposing TangerinixOS - A NixOS tailored for pentesting

Announcements
1

tangerinixos

A (humble) NixOS based alternative to Kali / Parrot.

Features:

  • Includes many packages helpful for security testing (thanks to the effort bringing such packages into nixpkgs: see NixOS for Pentesting Overview);
  • Easy to run as a VM thanks to nixos-generators;
  • Defaults some configuration options to values taken from the host (locale, keyboard layout, timezone).

Shortcomings:

  • High number of packages:
    • Build is long,
    • The store gets big,
    • Build can fail because of “lack of maintenance” of certain packages;
  • Incompleteness: many packages from Kali are not yet present in nixpkgs (see Are We Hackers Yet? for more details);
  • Customization is kinda tedious: clone the repo, edit the files, evaluate.

Moving forward (if ever)

  1. A good portion of the configuration (in particular the packages) could be moved to a NixOS profile to ease composability and parametrization;
  2. Improve customizability (probably leveraging NixOS profiles would already help (see 1.);
  3. Have some CI / caching (Hydra?) to 1) ensure packages are building properly, and 2) speed up evaluation.
14 Likes
2

If the build can fail, maybe you can lock nixpkgs to have a known good state of all packages? You can use GitHub - knl/niv-updater-action: A GitHub Action that creates meaningful pull requests with updates to your niv-managed dependencies, so you don't have to do menial chores. to automatically do updates and pull requests.

1 Like
3

  1. Is it desirable given its current “design” (I am not experienced enough to tell)?

    One of the main feature I was looking for was “inheriting” some configuration values from the host (locale, keyboard layout for example); If the host and the guest were using different nixpkgs, wouldn’t it cause some “duplicated” evaluations?
    It seems evident to me that it’s at least going to for packages (say I use neovim on the host, and it’s required in TangerinixOS)…

    More generally, sharing the /nix/store between the host and the guest is helping to have: fast rebuild, lower storage footprint, and consistency of packages version between the host and guest.
    All of that might be lost when using different versions of nixpkgs concurrently.

  2. Is that even possible? I mean, are we sure that there exist a revision of nixpkgs in which all the packages TangerinixOS relies on are evaluating properly?
    (maybe that’s what stable is for… I haven’t tried it, as all my machines use unstable and don’t have enough space…)

  3. Is that worth the engineering time?
    It’s meant to be more of a handy to use toolbox than a system that works 100% of the time… (especially with such a small user base - 0.25 on the last count, I don’t do pentesting full time ^^).

    And it feels like the value of maintaining a “stable subset of nixpkgs” is lower than actually stabilizing nixpgks itself by updating packages failing their evaluation.

4

You mean it’s not called PinkiNixOS? :joy_cat: Looking forward to learning more about this project!