Brainstorming: Auxolotls security story

This thread is an attempt to source ideas for what security in Auxolotl - the OS and the wider ecosystem could look like. And it want’s your input :wink:

During our first conversation COMSEC - 2024-05-04 - Meeting notes, the idea of writing a “Story for Security” came up as multiple people described their “grievances” with a lack of coordinated security in the wider ecosystem.

I see the idea of a “story” combining 2 aspects:

  • What and why is this important or should we be doing this?
    One way to imagine it is to describe a possible users journey with this feature. The more details the better :wink:

  • How can we do this. This does not need to be super doable right now, it can include some wishful thinking and dreaming where necessary.

If you have additional aspects to your idea, please do add them too, the 2 above are the ones I could think of.

I’ll be collecting all ideas and will try to come up with a summarized view at same later point. My personal hope is that this collection of “stories” can help us align security with what people want and need :crossed_fingers:


The story
In a perfect world, a declarative OS is using auto-generated, declarative secrets that are not stored in some vault, easy to rotate, impossible to leak (super-hard is OK too) and just super easy to handle.

They do not rely upon some unencrypted private key on disc (I’m :eyes: SSH priv host key) or a manual action on every boot, so I can scale them to hundreds or thousands of machines.

And for the view ones where I cant choose (API keys), a simple key-encryption-key scheme in the same tool solves my problem.

I feel inspired by a tool called gokey, here’s a description how cloudflare is using it

Plus we have wonderful mechanisms like TPMs (+ measured/ secure boot) or tang/clevis and maybe there’s even some diffie-hellman that spans time & space :thinking:


INTEGRATED secrets management seems like something that would be great for marketing ourselves (although that’s not important on its own, IMO, but maybe it’s a good idea intrinsically too).

1 Like

Overlapped! (But you said it better.)

1 Like

The story

I love my declaritive OS and I love my CI/CD pipeline that builds it. My auxolotl sources update themselves daily, notifying me about possible changes to my machines software stack.

A special variant of these notifications are security alerts. They tell me when it’s time to patch a my machines (or a subset) with all the necessary details about the security vulnerabilities.

The beauty of the setup is that my CI/CD needs no access to any machine. No general admin account that can be hacked, no network failures or flaky tests due to unreachable machines. The evaluation happens “purely” contained within the CI/CD system.

The awesome security team at auxolotl is providing my CI/CD with a datastream of vulnerable packages, frequently updated and easily consumable in an automated test.

Whenever my sources (flake inputs) update my CI/CD simply goes

  • eval systems
  • build systems
  • run tests


The Story

I have a really clear idea of how and when the people behind my operating system consider CVEs.


See COMSEC - 2024-05-04 - Meeting notes for ideas


Ooh I just watched this and now I need to dig into gokey. Something like this has been what I have been searching for!

1 Like

A general goal I think Aux should have is improving ergonomics. I think when it comes to security, users should be able to trust Aux to “do the right thing” by default. That doesn’t quite mean “secure by default”—which as pointed out in the meeting is a bit of a buzz-phrase—but what it does mean is that the user should be “at ease”, that security should be as “easy” as possible. To give a simple example, assuming we have an aux CLI, there should be an aux audit command that does basic security checks. Assuming we have an installer, App Armor should be enabled by default, etc.


Yeah gokey is pretty amazing! If you combine it with a TPM you should be pretty golden.

And maybe (for some more sugar) drand as initial entropy on a linux system is kinda sucky $ME_DREAMING


A few more random items that have been mentioned in other discussions or popped into my mind

  • Signed installers & ISOs
  • Post-Quantum crypto support/ enforcement
  • SELinux/LMS support & challenges
  • Secure Boot
  • Adoption of core libraries written in memory safe languages (OpenSSL discussion)
  • systemd unit hardening
  • Secure (Authenticated) NTP
  • Default application sandboxing (e.g. Browser/ email client)

Please let me know if these are the types of userstories you’re looking for or if you would like any clarifications:

Aux user userstory
As an Aux user I want to know that my systems are secure and up to date but I don’t want any functionality to change in the updates. Ideally, I would like to do an attended update but there are times where I want a critical vulnerability to be automatically patched (after an scheduled security check service runs). I would prefer the service/function to stop working if the vulnerability cannot be patched “live”. However, this behavior should only happen for critical vulnerabilities and I trust the Aux security team to determine that classification.

Aux system administrator userstory
As an Aux system administrator I would also like to know which configurations require updated by running an audit command on a repo (local or remote) accessible to the CLI. This will allow me to audit configurations that are not even associated with the current system in any shape. For instance, audit a family/work/community related repo without logging into the remote system. This would allow me to schedule audits to run against specified repos/configs and decide how I want to deal with the findings.


The story
I care a bit about security, but unfortunately I’m not very good at remembering to do anything about it. I often leave package updates too long, and when I installed NixOS somehow setting up secure boot was always a job for “next weekend”.

Happily, auxolotl made it much easier. My aux configuration has had secure boot from day 1, it never became a task to do later. While Aux still lets me do package updates late as I please, it sends me a notification if there are security fixes which I might want to update for.


  • When I ran the installer, Aux took me through some steps, one of which was setting up secure boot. It generated some keys and helped me install them, adding the relevant section to my initial config
  • My configuration inputs are locked, but Aux runs a daemon which downloads security advisories from their security team.
    • If there are any, Aux lets me know about it both by sending an immediate notification to my of choice, and – in case I miss that or have not set up my notification daemon – by exposing it in other places in the operating system, such as in a hook which automatically runs when I launch a terminal and in snowfall’s nix-software-center.

A post was split to a new topic: Replace standard utilities with rust

Some more I found in @danderson post: Ideas for a 'ideal' nix-based distro - #11 by danderson?

  • system integrity (dm-crypt + dm-integrity + TPM)
  • systemd’s TPM-bound credential storage
  • remote attestation
  • rapid build & distribution of security fixes

Regarding system integrity: There’s GitHub - nix-community/lanzaboote: Secure Boot for NixOS [maintainers=@blitz @raitobezarius @nikstur] “This repository contains tooling for UEFI Secure Boot on NixOS. The goal is to make Secure Boot available from nixpkgs for any platform that supports UEFI.”. Might be interesting to look into.


I have a story around users and distributed builds:

For context, I set up my home server as a build host using nix.buildmachines. On both my local and build host, I have my user account added to nix.settings.allowed-users, along with root. In my local host config, I have nix.distributedBuilds = true;. I can also SSH into the build host from my local host as my user.

The issue is that in order to build a NixOS generation, you need root access. Makes sense, since Nix needs to create the symlinks and boot entries. The problem I have is that Nix requires you to give the root user the ability to SSH into the build system. It should already be possible for my regular user account to SSH into the build host, run the build, copy it back, and then switch to root to install it. But instead, it seems like Nix switches to root before SSHing ointo the server.

Why is this important?
Giving root the ability to SSH seems unnecessary, since my user already has SSH set up and can already run builds both locally and remotely. It’s not a huge deal because it’s not like I’m SSHing into root on the remote server, but it still feels unnecessary.

How can we do this?
Use the logged-in local user’s SSH config to connect to the remote host, run the build, copy it back, and then request root privileges. (I don’t know cppNix’s code base well, but it looks like it happens here? nixpkgs/pkgs/os-specific/linux/nixos-rebuild/ at 8e9745496f2c3b4da48dc1aac628c5644c55525c · NixOS/nixpkgs · GitHub)


I think the Lix folks were discussing this in their general Matrix channel yesterday evening. They seem to have some fairly concrete plans to improve the build process, so worth keeping track of how they get on.


2 posts were split to a new topic: Should we use gittuf?