5 ms·

For the curl command though written like it won't show up in history, this will still show up in process parameters To fix this as well pass it into curl as a

by mauli 5y ago

For the curl command though written like it won't show up in history, this will still show up in process parameters To fix this as well pass it into curl as a config via eg: curl [...] -K- <<< "--header auth:$(pass mysecret)"

vesinisa 5y ago
curl -H/--header itself also takes a file name prefixed by @, including - for stdin. So you could go curl -H@- <<<'API-Key: Foobar', or if you need to specify multiple sensitive headers, curl -H@<(echo API-Key: Foo) -H@<(echo Pre-Shared: Bar)
- remram 5y ago
  <() is a bash extension and won't work in another `sh` like dash.
hvdijk 5y ago
And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.
- throwawayboise 5y ago
  I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?
  - MayeulC 5y ago
    Just try to change it by yourself: https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ https://www.cyberciti.biz/faq/linux-hide-processes-from-othe... sudo mount -o remount,hidepid=1 /proc
  - zokier 5y ago
    > What if non-root could see their own processes in detail, but only the program name for other users' processes? At which point you might as well ask why do you need to see other users processes at all? And indeed, that is an option in grsec. I don't think it causes any major breakage, but there are probably some xkcd #1172 sort of things that break. edit: apparently there is nowdays also options in mainline for that too: https://pipo.blog/articles/20130930-hidepid-process-hiding https://pipo.blog/articles/20130930-hidepid-process-hiding and also possibly with selinux?
  - mauli 5y ago
    Hi, great question. Have not seen it being enabled break anything so far (only some cross user invouse written process monitoring scripts). Linux has a flag for this for the /proc mountpoint: hidepid=2
  - deleted 5y ago
    [deleted]
  - stevekemp 5y ago
    Take a look at the `hidepid` option which is available to the /proc filesystem these days: https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ https://www.cyberciti.biz/faq/linux-hide-processes-from-othe... Biggest surprise is that people can't run top/ps to see where load is coming from, but that aside I never noticed any particular downsides.
  - yrro 5y ago
    You can do this by mounting procfs with the hidepid= option. But it breaks systemd when enabled system-wide: https://github.com/systemd/systemd/issues/12955 https://github.com/systemd/systemd/issues/12955 Individual units can opt-in to this behaviour with the ProtectProc= option though. But I don't think there's currently a good way to apply it to users' interactive processes.
  - mehdix 5y ago
    Most other users nowadays are likely to be your webserver, your application process, your database, your crawler, and a myriad of other long-running processes.

by mauli 5y ago

vesinisa 5y ago

curl -H/--header itself also takes a file name prefixed by @, including - for stdin. So you could go curl -H@- <<<'API-Key: Foobar', or if you need to specify multiple sensitive headers, curl -H@<(echo API-Key: Foo) -H@<(echo Pre-Shared: Bar)

remram 5y ago
<() is a bash extension and won't work in another `sh` like dash.

hvdijk 5y ago

And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.

throwawayboise 5y ago
I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?
- MayeulC 5y ago
  Just try to change it by yourself: https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ https://www.cyberciti.biz/faq/linux-hide-processes-from-othe... sudo mount -o remount,hidepid=1 /proc
- zokier 5y ago
  > What if non-root could see their own processes in detail, but only the program name for other users' processes? At which point you might as well ask why do you need to see other users processes at all? And indeed, that is an option in grsec. I don't think it causes any major breakage, but there are probably some xkcd #1172 sort of things that break. edit: apparently there is nowdays also options in mainline for that too: https://pipo.blog/articles/20130930-hidepid-process-hiding https://pipo.blog/articles/20130930-hidepid-process-hiding and also possibly with selinux?
- mauli 5y ago
  Hi, great question. Have not seen it being enabled break anything so far (only some cross user invouse written process monitoring scripts). Linux has a flag for this for the /proc mountpoint: hidepid=2
- deleted 5y ago
  [deleted]
- stevekemp 5y ago
  Take a look at the `hidepid` option which is available to the /proc filesystem these days: https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ https://www.cyberciti.biz/faq/linux-hide-processes-from-othe... Biggest surprise is that people can't run top/ps to see where load is coming from, but that aside I never noticed any particular downsides.
- yrro 5y ago
  You can do this by mounting procfs with the hidepid= option. But it breaks systemd when enabled system-wide: https://github.com/systemd/systemd/issues/12955 https://github.com/systemd/systemd/issues/12955 Individual units can opt-in to this behaviour with the ProtectProc= option though. But I don't think there's currently a good way to apply it to users' interactive processes.
- mehdix 5y ago
  Most other users nowadays are likely to be your webserver, your application process, your database, your crawler, and a myriad of other long-running processes.