3 ms·

I prefer to pass secrets between programs through standard input

62 points by ingve 9mo ago

kevin_thibedeau 9mo ago
> Unfortunately you're using a browser (or client library) that my anti-crawler precautions consider suspicious because it's sending inconsistent values for Sec-CH-UA-* HTTP request headers... The world doesn't exclusively use Chrome. Nice to see even the nerds are contributing to the closed web.
- edwcross 9mo ago
  I'm using Firefox and didn't see that message.
  - swiftcoder 9mo ago
    Nor on Safari. I wonder what exotic browser the parent is using?
    - ErroneousBosh 9mo ago
      Doesn't appear to be Firefox, Chrome, Chromium, Edge, or Falkon on Linux, doesn't appear to be Falkon on Haiku. I also wonder what they're using and where can I get some so I can break stuff too?
      - guerrilla 9mo ago
        > Falkon In case anyone is wondering: https://www.falkon.org/about/ https://www.falkon.org/about/
- efilife 9mo ago
  I am on ungoogled chromium and I see this
- mhitza 9mo ago
  Also site is not accessible via Mullvad VPN.
  - figmert 9mo ago
    I am on Mullvad (at the router), and I am able to connect.
    - mhitza 9mo ago
      Checks out, it was my preferred exit node.
      - sn9 9mo ago
        I had to disconnect Mullvad to load the page.
  - zxcvasd 9mo ago
    i am on mullvad and accessing it fine. if you are on one of the default exit nodes, try switching it. i find the default nodes get blocked by a lot of sites, likely due to malicious behavior of other users.
- zxcvasd 9mo ago
  [dead]
- Alex-Programs 9mo ago
  It's also moaning about me coming from a datacentre IP (proxy) with some vague complaints about load introduced by AI crawlers. I think this guy treats "protecting" his site as a hobby.
- deleted 9mo ago
  [deleted]
- 7e 9mo ago
  Not working well with something that doesn't conform to the WICG User-Agent Client Hints specification is an interesting definition of "closed." More like, "I have standards." And it's hardly closed if you can get the information by using literally almost any other client.
Dwedit 9mo ago
I haven't actually tested this, but aren't the input and output handles exposed on /proc/? What's stopping another process from seeing everything?
- trashb 9mo ago
  Yes pipes are exposed /proc/$pid/fd/$thePipeFd with user permissions [0]. Additionally command line parameters are always readable /proc/$YOUR_PROCESS_PID/cmdline [1] There are workarounds but it's fragile. You may accept the risks and in that case it can work for you but I wouldn't recommend it for "general security". Seems it wouldn't be considered secure if everyone did it this way, therefore is it security through obscurity? [0] https://unix.stackexchange.com/questions/156859/is-the-data-transiting-through-a-pipe-confidential https://unix.stackexchange.com/questions/156859/is-the-data-... [1] https://stackoverflow.com/questions/3830823/hiding-secret-from-command-line-parameter-on-unix https://stackoverflow.com/questions/3830823/hiding-secret-fr...
- Lex-2008 9mo ago
  not a Linux expert, but I believe that at the very least it's time sensitive: after consumer process reads it, it's gone from the pipe. Unlike env vars and cli argument that stay there.
- Tajnymag 9mo ago
  I guess the kernel is stopping that. I don't think permission wise you'd have the privileges to read someone else's stdin/out.
juancn 9mo ago
I used to do that, I had a sort of IDE that launched a local server, bound to localhost. The launching process would send a random password through stdin to the child after launch, and the child would use that to authenticate the further RPC calls. It's surprisingly hard to intercept a process' stdin stream.
pvtmert 9mo ago
Interesting approach. I like Docker/Kubernetes way of secret mounts where you can limit user/group permissions too. Meanwhile, I was an avid user of the echo secret | ssh consume approach, specifically for the kerberos authentication. In my workflow, I saved the kerberos password to the macOS keychain, where kinit --use-keychain authenticated me seamlessly. However this wasn't the case for remote machines. Therefore, I have implemented a quick script that is essentially security find-generic-password -a "kerberos" -s "kerberos-password" -w | ssh user@host kinit user@REALM Which served me really good for the last 4~years.
stale-labs 9mo ago
[flagged]
- reliefcrew 9mo ago
  > The main practical win is that cmd args show up in `ps aux` for anyone on the system to see, whereas stdin keeps it off that list. For those interested, re-mounting /proc with hidepid can prevent this: `mount -o remount,rw,hidepid=2 /proc`
blibble 9mo ago
linux has a key api that works pretty well man keyctl
azornathogron 9mo ago
For one of my projects my server needs a private key, and it reads this from a file descriptor on startup and then closes the fd. The fd is set up by the systemd unit, which is also configured to restrict filesystem access for the server. So the server reads a key from a file that is never visible in its mount namespace.
- computerfriend 9mo ago
  I do something similar with LoadCredential and it is quite amazing, especially when you want to run the application as a dynamic user.
- infogulch 9mo ago
  If you keep the fd open maybe you could read refreshed secrets through it for live secret rotation.
Spivak 9mo ago
For your actual production systems you might consider systemd-creds along with the LoadCredential= and LoadCredentialEncrypted= directives which do the* right thing. Nothing is exposed and credentials are placed in non-swappable memory. You can even have your credentials encrypted at rest with your system's TPM. * Well, one of the correct ways of doing this.
vagab0nd 9mo ago
Interesting article. What prevents me from dumping the memory of the shell process and reading the local variable? My program requires a password on startup. To run it in a loop, I used a script that takes the password as input, stores it in a local variable, and echoes it to the program. At the time I thought the only weakness was the memory of the shell process. But it was the best I could come up with.

62 points by ingve 9mo ago

> Unfortunately you're using a browser (or client library) that my anti-crawler precautions consider suspicious because it's sending inconsistent values for Sec-CH-UA-* HTTP request headers... The world doesn't exclusively use Chrome. Nice to see even the nerds are contributing to the closed web.

edwcross 9mo ago
I'm using Firefox and didn't see that message.
- swiftcoder 9mo ago
  Nor on Safari. I wonder what exotic browser the parent is using?
  - ErroneousBosh 9mo ago
    Doesn't appear to be Firefox, Chrome, Chromium, Edge, or Falkon on Linux, doesn't appear to be Falkon on Haiku. I also wonder what they're using and where can I get some so I can break stuff too?
    - guerrilla 9mo ago
      > Falkon In case anyone is wondering: https://www.falkon.org/about/ https://www.falkon.org/about/
efilife 9mo ago
I am on ungoogled chromium and I see this
mhitza 9mo ago
Also site is not accessible via Mullvad VPN.
- figmert 9mo ago
  I am on Mullvad (at the router), and I am able to connect.
  - mhitza 9mo ago
    Checks out, it was my preferred exit node.
    - sn9 9mo ago
      I had to disconnect Mullvad to load the page.
- zxcvasd 9mo ago
  i am on mullvad and accessing it fine. if you are on one of the default exit nodes, try switching it. i find the default nodes get blocked by a lot of sites, likely due to malicious behavior of other users.
zxcvasd 9mo ago
[dead]
Alex-Programs 9mo ago
It's also moaning about me coming from a datacentre IP (proxy) with some vague complaints about load introduced by AI crawlers. I think this guy treats "protecting" his site as a hobby.
deleted 9mo ago
[deleted]
7e 9mo ago
Not working well with something that doesn't conform to the WICG User-Agent Client Hints specification is an interesting definition of "closed." More like, "I have standards." And it's hardly closed if you can get the information by using literally almost any other client.

Dwedit 9mo ago

I haven't actually tested this, but aren't the input and output handles exposed on /proc/? What's stopping another process from seeing everything?

trashb 9mo ago
Yes pipes are exposed /proc/$pid/fd/$thePipeFd with user permissions [0]. Additionally command line parameters are always readable /proc/$YOUR_PROCESS_PID/cmdline [1] There are workarounds but it's fragile. You may accept the risks and in that case it can work for you but I wouldn't recommend it for "general security". Seems it wouldn't be considered secure if everyone did it this way, therefore is it security through obscurity? [0] https://unix.stackexchange.com/questions/156859/is-the-data-transiting-through-a-pipe-confidential https://unix.stackexchange.com/questions/156859/is-the-data-... [1] https://stackoverflow.com/questions/3830823/hiding-secret-from-command-line-parameter-on-unix https://stackoverflow.com/questions/3830823/hiding-secret-fr...
Lex-2008 9mo ago
not a Linux expert, but I believe that at the very least it's time sensitive: after consumer process reads it, it's gone from the pipe. Unlike env vars and cli argument that stay there.
Tajnymag 9mo ago
I guess the kernel is stopping that. I don't think permission wise you'd have the privileges to read someone else's stdin/out.

juancn 9mo ago

I used to do that, I had a sort of IDE that launched a local server, bound to localhost. The launching process would send a random password through stdin to the child after launch, and the child would use that to authenticate the further RPC calls. It's surprisingly hard to intercept a process' stdin stream.

pvtmert 9mo ago

Interesting approach. I like Docker/Kubernetes way of secret mounts where you can limit user/group permissions too. Meanwhile, I was an avid user of the echo secret | ssh consume approach, specifically for the kerberos authentication. In my workflow, I saved the kerberos password to the macOS keychain, where kinit --use-keychain authenticated me seamlessly. However this wasn't the case for remote machines. Therefore, I have implemented a quick script that is essentially security find-generic-password -a "kerberos" -s "kerberos-password" -w | ssh user@host kinit user@REALM Which served me really good for the last 4~years.

stale-labs 9mo ago

[flagged]

reliefcrew 9mo ago
> The main practical win is that cmd args show up in `ps aux` for anyone on the system to see, whereas stdin keeps it off that list. For those interested, re-mounting /proc with hidepid can prevent this: `mount -o remount,rw,hidepid=2 /proc`

blibble 9mo ago

linux has a key api that works pretty well man keyctl

azornathogron 9mo ago

For one of my projects my server needs a private key, and it reads this from a file descriptor on startup and then closes the fd. The fd is set up by the systemd unit, which is also configured to restrict filesystem access for the server. So the server reads a key from a file that is never visible in its mount namespace.

computerfriend 9mo ago
I do something similar with LoadCredential and it is quite amazing, especially when you want to run the application as a dynamic user.
infogulch 9mo ago
If you keep the fd open maybe you could read refreshed secrets through it for live secret rotation.

Spivak 9mo ago

For your actual production systems you might consider systemd-creds along with the LoadCredential= and LoadCredentialEncrypted= directives which do the* right thing. Nothing is exposed and credentials are placed in non-swappable memory. You can even have your credentials encrypted at rest with your system's TPM. * Well, one of the correct ways of doing this.

vagab0nd 9mo ago

Interesting article. What prevents me from dumping the memory of the shell process and reading the local variable? My program requires a password on startup. To run it in a loop, I used a script that takes the password as input, stores it in a local variable, and echoes it to the program. At the time I thought the only weakness was the memory of the shell process. But it was the best I could come up with.