linuxhackerman

6개월 전discuss

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

6개월 전discuss

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

6개월 전discuss

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

6개월 전discuss

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

6개월 전discuss

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

6개월 전discuss

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

3년 전discuss

"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

4년 전discuss

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

4년 전discuss

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

linuxhackerman

4년 전discuss

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