this post was submitted on 05 Aug 2023
5 points (100.0% liked)

NixOS

992 readers
1 users here now

NixOS is a Linux distribution built on top of the Nix package manager. Its declarative configuration allows reliable system upgrades via several official channels of stability and size.

This community discusses NixOS, Nix, and everything related.

founded 1 year ago
MODERATORS
 

I have a config that I share on github. I share the whole thing and there are keys in it but they are obviously not the complete key (as is standard throughout the community). Just enough to point to the real key with Nix.

Anyway, I have finally gotten around to learning the power of git-crypt. Today, I went through my whole config and took everything out that could even remotely be used by a hacker to find out security holes in my config (permitted insecure packages, specific hardware ID's, github username and email address, for example all went into nix files into the secrets folder with imports where they used to reside) and put those files into a folder at top level called secrets. Then, I encrypted all of the files in that folder and pointed the rest of the config to them so they remain encrypted on my github but perfectly usable in evaluation and build of my config derivation.

My question is: Have I done something clever that will significantly decrease the chances of exploit or do you recommend that everyone does this and I'm just late to the security party?

If this technique is just standard, what else could one do to harden their system without causing difficult to solve issues on deployment of their config? For example, I now need to decrypt that folder when I use that config on a new system and anyone else building it wouldn't be able to get through the evaluation.

I've heard of Sops-Nix and other such security handlers. How can I use sops-nix to aid in that initial git-crypt setup when I spin up a new system, for example?

you are viewing a single comment's thread
view the rest of the comments
[–] kereshnull@infosec.pub 3 points 1 year ago

Good job for doing something. It all boils down to what you are comfortable with, adding security will always add a certain level of inconvenience. Ideally the next step would be to fully automate what you have.

Elaborate does not mean secure, often it's the opposite as adding complexity adds new ways of failure.

If you are talking about this SOPS https://github.com/getsops/sops it doesn't change much you need to store the master key somewhere. It makes it easier to operate, but your trust boundary does not move.