3 ms·

> On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especi

> On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. This is a very good point I'd never realised! I'm not sure how you get around it, though, as if that program can even find a credential and decrypt a file, if it runs as the user then everything else can go find that credential as well.

rsyring 1y ago
I added a note to my original post about how 1Password's cli tool work. Access to the binary doesn't mean automatic access to any authorized session. I think that's a good start. In my case, I have it tied into my fingerprint reader, so if something want's access to a secret using `op` I get a prompt to authorize. If I haven't just called `op` myself, I know it's a suspect request.
chasil 1y ago
If a root exploit is leveraged, then /proc/*/environ of all processes is visible to the adversary. The classical alternative has been to store (FTP) credentials in a .netrc file (also used by curl). I have some custom code to pull passwords out of a SQLite database. For people who are really concerned with this, a "secrecy manger" is more appropriate, such as Cyberark conjur and summon, or Hashicorp Vault.
- jkrejcha 1y ago
  If a full root exploit is leveraged, it's already game over already, basically anything at that point is just going to be rearranging deck chairs.
- robertlagrant 1y ago
  > If a root exploit is leveraged, then /proc/*/environ of all processes is visible to the adversary. > The classical alternative has been to store (FTP) credentials in a .netrc file (also used by curl). You're not suggesting that a netrc file would stop a root exploit?

3 ms·

> On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especi

by robertlagrant 1y ago

rsyring 1y ago
I added a note to my original post about how 1Password's cli tool work. Access to the binary doesn't mean automatic access to any authorized session. I think that's a good start. In my case, I have it tied into my fingerprint reader, so if something want's access to a secret using `op` I get a prompt to authorize. If I haven't just called `op` myself, I know it's a suspect request.
chasil 1y ago
If a root exploit is leveraged, then /proc/*/environ of all processes is visible to the adversary. The classical alternative has been to store (FTP) credentials in a .netrc file (also used by curl). I have some custom code to pull passwords out of a SQLite database. For people who are really concerned with this, a "secrecy manger" is more appropriate, such as Cyberark conjur and summon, or Hashicorp Vault.
- jkrejcha 1y ago
  If a full root exploit is leveraged, it's already game over already, basically anything at that point is just going to be rearranging deck chairs.
- robertlagrant 1y ago
  > If a root exploit is leveraged, then /proc/*/environ of all processes is visible to the adversary. > The classical alternative has been to store (FTP) credentials in a .netrc file (also used by curl). You're not suggesting that a netrc file would stop a root exploit?