TL;DR
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
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
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
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 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.
How?
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
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).
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.
How?
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
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.
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.
How?
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 freedesktop.org-notification-compatible-daemon 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.
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.
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.
SSH priv host key) or a manual action on every boot, so I can scale them to hundreds or thousands of machines.