I prefer to pass secrets between programs through standard input(utcc.utoronto.ca)

40 pointsby ingve4 hours ago7 comments

kevin_thibedeau3 hours 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.
- Alex-Programs2 hours 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.
- edwcross3 hours ago
  I'm using Firefox and didn't see that message.
  - swiftcoder3 hours ago
    Nor on Safari. I wonder what exotic browser the parent is using?
    ErroneousBosh3 hours 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?
    guerrilla2 hours ago
    > Falkon
    In case anyone is wondering: https://www.falkon.org/about/
- an hour ago
  undefined
- mhitza2 hours ago
  Also site is not accessible via Mullvad VPN.
  - figmert2 hours ago
    I am on Mullvad (at the router), and I am able to connect.
    mhitza2 hours ago
    Checks out, it was my preferred exit node.
  - zxcvasd2 hours ago
    [dead]
- efilife3 hours ago
  I am on ungoogled chromium and I see this
- zxcvasd2 hours ago
  [dead]
azornathogron2 hours 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.
- computerfriend2 hours ago
  I do something similar with LoadCredential and it is quite amazing, especially when you want to run the application as a dynamic user.
juancn3 hours 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.
stale-labs2 hours 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.
re: the /proc concerns - true, but if someones got same-user access to read your /proc/pid/fd, they can probably ptrace you or read process memory anyway. stdin is more about basic hygiene than stopping sophisticated attackers.
tbh for anything actually sensitive I've been leaning toward tmpfs files with strict perms, or using something like vault/age. stdin is a nice middle ground tho for quick scripts.
- reliefcrewan hour 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`
Dwedit3 hours 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?
- trashb2 hours 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-...
  [1] https://stackoverflow.com/questions/3830823/hiding-secret-fr...
- Lex-20082 hours 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.
- Tajnymag2 hours 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.
pvtmert3 hours 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.
blibble2 hours ago
linux has a key api that works pretty well
man keyctl