linuxhackerman

há 6 mesesdiscuss

This is indeed a useful approach to limiting the scope of environment variables, and I try to use that rather than exporting when possible. Using files (especially "special" files like the command-substitution fd reference) is still preferable by a wide margin, and I hope that applications trend towards using files as the primary mechanism for passing in secrets.

linuxhackerman

há 6 mesesdiscuss

As pointed out by evgpbfhnr, I do avoid using environment variables and justify it (though with different reasoning than yours).

Your justification is the kind of thing I mention as out-of-scope (for my purposes!) in my conclusion:

> There are also many bases that I don’t cover and routes through which sufficiently-smart malware could easily still obtain the secrets I’m working with.

/proc/$pid/environ, /proc/$pid/mem and other such vectors (ptrace, bpftrace, equivalents on other platforms) are real, but:

- they're not vectors of _accidental_ leakage like dumping the full process environment to logs or shell history are

- they rely on privileged access existing at the time that I'm handling the secret, while logs or shell history can be obtained _in the future_

- they're not the kind of thing I expect broad-spectrum malware to go rooting for: the memory of all processes is a lot of data to classify/exfiltrate, and if I were a malware author I'd fear that that would be far too resource-intensive and thus conspicuous. Browser cookie storage, password manager databases, keylogging, and the like are much easier and more valuable pickings.

linuxhackerman

há 6 mesesdiscuss

Process substitution (the `<(echo ...)` approach I used in the post) is practically equivalent to this, creating a path that can be read by the shell and its child processes (and, at least as expanded, _only_ by them) just like a named FIFO -- but without the race condition mentioned by SoftTalker.

What you've hinted at and what I didn't mention in the post is that this is indeed a good way to avoid even having the secret ever be a shell variable. It's a bit of extra fiddling to turn just the token into the Authorization header, but it's certainly possible, something like this:

curl -H @<(rbw get gitlab-access-token | sed 's/^/Authorization: Bearer/') https://gitlab.example.com/api/v4/projects

linuxhackerman

há 6 mesesdiscuss

I touch on this possibility with the `rbw` example:

>`$ token=$(rbw get gitlab-access-token) # get the token from a command-line password manager`

linuxhackerman

há 6 mesesdiscuss

It's definitely a powerful approach; I don't think it's particularly viable for the sort of use cases where you're throwing secrets around in a shell:

- It's not supported natively by most software (if I wanted to use it with `curl` for example, it would only be able to replace the `rbw` example since I still need to pass the secret to curl somehow);

- I don't think it's likely to gain widespread adoption, due to being a linux-specific API;

- The API itself suffers from some poor design choices, imho; it is not currently possible to set an expiry on a keyring entry without an intermediate state where the data is loaded but no expiry is set: https://lore.kernel.org/keyrings/ygar0hbrm05.fsf@localhost/T...

It's really nice as a concept and when you're developing an application where you control the entire flow of the secret data, but I don't see much practical value in it for general use cases. Exposing it as a filesystem could be a potential bridge for application support (something like `curl -H @</proc/self/keyring/@u/gitlab-authorization-header`?), though I suspect that wouldn't fly upstream because files aren't generally treated as carefully as explicit secret things. Non-enumerability (`-r` on `/proc/self/keying` and `/proc/self/keyring/*`) would help here, but I still seriously doubt that the keyring maintainers would find this to be a sane proposition :)

linuxhackerman

há 6 mesesdiscuss

As I mention in the post:

>One way to avoid this is to prevent the command from being written to history. Bash has a configuration variable named HISTCONTROL, which when set to include ignorespace prevents commands prefixed with whitespace from being saved in history.

linuxhackerman

há 3 anosdiscuss

"reproducible" means you get the same result, bit-for-bit, when running a build in different circumstances.

It's trivial to write non-reproducible Nix derivations by placing timestamps, randomly generated data, or similar into the build output, directly or indirectly. Nix is a powerful tool for working towards reproducibility, since it can specify the software side of a build environment more exhaustively than most other package managers out there, and has a language (derivations) that enables repeating builds easily as well as comparing them, but does not guarantee reproducibility on its own.

A lot of the reproducibility of nixpkgs is attributable to reproducible build efforts elsewhere, including conventions like SOURCE_DATE_EPOCH. Nix itself does not in fact "freeze the clock" for builds, but many tools that use timestamps as part of a build will respect SOURCE_DATE_EPOCH instead of using the system clock. Many of these valuable developments in this direction are coordinated in the cross-distro https://reproducible-builds.org group.

linuxhackerman

há 4 anosdiscuss

I've been planning to implement NixOS tests based on virtiofs instead of 9p for a while, but haven't got it working yet (at the time I tried, the available uid mapping strategies didn't cover what was needed for NixOS tests; there's a patch which I haven't got around to trying out yet though.) and this big improvement takes the pain away a bit so my motivation to finish that off is lower. I'll be sure to write about it if I do though!

linuxhackerman

há 4 anosdiscuss

Great job, me. I fixed it in the source but didn't deploy it to the site. Thanks for pointing it out!

linuxhackerman

há 4 anosdiscuss

It doesn't actually go through a "real network" at all, the VM speaks 9p to the host via a virtio pipe (not sure what the technically correct term for this is) so there's none of the overhead that you'd have with emulating a network device and encapsulating it all in Ethernet/IP/TCP.

comments