daboross

Dabo

@daboross

  • they/them

@daboross-pottery

For future reference: https://daboross.net/. Blog & RSS feed not yet built as of 2024-09-13.

log inask
post-cohost newsletter
buttondown.com/daboross/
daboross
@daboross
lexi
@lexi
lexi
@lexi

have not been online™ recently but figured this place would be the best to ask:

does a secret manager for linux, preferably working with nix, which actually like enforces that only specific programs can access the secrets, exist?

like, my jellyfin server doesn't need access to my github oauth secrets, and if i dont want to create a separate user for every non-shared secret it seems that i am kind of fucked

pretty much every secret manager out there either tries to use vanilla unix permissions, which sucks because id like to run stuff as myself, or puts secrets (encrypted or not i do not give a rats ass) in a world (or user) readable place, which in my humble opinion is an incredibly bad idea and id really like to avoid that

and, like, especially with nix this should be possible? you whitelist certain binary in the nix store, and only that binary ran from my user can ask for the secrets, and gets it into its memory (in the best case wrapped in something like Zeroing<T>). you have to do some precautions like setting secure-execution mode for ld.so (and maybe even lock environment variables, nix build-esque)

that should make secrets practically unstealable. but it just, doesnt seem to exist. is everyone okay with just handing around your secrets to anything that runs on your computer like its nothing? i get that most people dont care about threat models etc, but i do not want to write my secrets into /nix/store. like, please do correct me if it should exist, but this really looks like i am gonna have to roll my own secret mgmt

You must log in to comment.

in reply to @lexi's post:

nys
@nys

i’ll see if i can find it but i once accomplished something similar using SELinux. this is also reminding me of some openBSD thing but nothing NixOS related comes to mind immediately.

login to reply
cyberslak
@cyberslak

If you want true per-binary access control, AppArmor or SELinux are probably the way to go. It seems to me like standard Unix permissions can approximate it, though: you can use per-secret groups and set mode g=r,uo=, so only processes in the group can access it, and run processes with that group added. If you're using systemd services, setting SupplementaryGroups=<group> works, and you can do it for one-shot processes using systemd-run. That way, you still run processes as your user, but give them specific access using the supplementary group.

login to reply
lexi
@lexi

i've thought about using groups, but it has one huge vulnerability: if i have a binary that can access a file via groups, i can still try to exploit "vulnerabilities" in the binary like setting $PATH, $LD_PRELOAD, just overriding the binary or flaws in the logic via commandline args. if i'm able to extract secrets like that, the whole concept is useless and i can just go back to using sops again. but if my secret manager checks the env vars, commandline etc. this can be mostly prevented.

this may be possible with AppArmor or SELinux, but i have no clue how either of those work and i'm pretty sure that this also works without them

login to reply
lexi
@lexi

ive actually thought about just extending sops (and sops-nix), but i think i'm either gonna write a pretty thick wrapper or my own thing based on GPG and friends because i do disagree with a couple of choices from sops!

for example, getting your (decrypted or encrypted) key file stolen is pretty unlikely, but seems to be completely excluded from the threat model? the object keys (as in K/V) still being plain text ruins any kind of plausible deniability, and everything is encrypted with the same key if you don't keep a million sops files around. for example you could hash the keys (as in K/V), and do two layers of encryption, doing something along the lines of secret-manager get $(echo "my-key" | sha256sum) | openssl enc -aes-256-cbc -d -K "abc123" so you'd need both the decrypted keyfile and the place where it gets decrypted, which would massively reduce impact if shit does hit the fan.

and another thing that kinda grinds my gears is how there is no immutability and no verification of the output. like, if i use a secret in a nix derivation i'd like that secret to actually stay the same for reproducibility, but that just kinda, doesn't seem to be the case? and, even nix aside that seems to be a bad thing security-wise that you can just, swap secrets out because you trust that your secret manager gives you the correct secret? i've had the pretty neat idea that you can just combine the unencrypted key (as in K/V) problem with this one by using (and verifying) a (salted) output hash as the actual key (as in K/V) to solve both of them (do note that this one was a 3am idea and i am not 100% sure if this is a good idea yet, but it sounds very promising)

and like, if i make a bunch more changes i'm not sure if writing a sops-ng would even make sense if it's easier to write my own thing lol

but yeah i am very heavily considering writing something along the lines of a sops-nix-ng thingy, because nix secret management seems to be an area that could need some improvement, and even though i am actively contributing to https://xkcd.com/927/, i think this could genuinely be a better alternative for nerds who like threat models and encryption

login to reply
Pinned Tags