4 ms·

I'm surprised this isn't higher up. Are there any arguments against ENV variables in favor of something else?

marcus 11y ago
ENV variables are inherited by child processes by default, so please use care when using this approach.
smtddr 11y ago
Here's my caution to this. If low level processes can do "ps aux", and they see something like: DB_USER=scott DB_PASSWORD=b3withm3pl3aze /usr/bin/python webapp.py That could be troublesome if an attacker figured out a way to run remote commands on your server even as an unprivileged user.
- yrro 11y ago
  Reading the environment of another process is a privileged operation.
  - vidarh 11y ago
    The example above is someone who have stupidly started a process with the environment variables exposed on the command line
    - yrro 11y ago
      Ok, but that's not a problem caused by the exposure of the environment, it's caused by the exposure of the command line.
      - vidarh 11y ago
        I agree - I was just explaining what the issue the above commenter raised. It just means you should use a saner way of initializing your environment with sensitive values.
  - smtddr 11y ago
    If an attacker can get the process that's running the webapp.py to exec some abitrary bash command, that process has the ability to read its own /proc/$PID/environ . In general, you can read /proc/$PID/environ on processes that you own. At least I can do that on my Debian system: pikachu@POKEMONGYM ~ $ sleep 99 & [1] 21340 pikachu@POKEMONGYM ~ $ cat /proc/21340/environ XDG_SESSION_ID=5COMP_WORDBREAKS= "'><;|&(:TERM=screenSHELL=/bin/bashXDG_SESSION_COOKIE=8571b679eed8952dd96ad28a54...<etc> (I actually gave the wrong example in my previous comment. While it is true that giving the ENV on cmdline will show up in ps eaux, the more appropriate example is what I just explained in this comment.)
    - tokenizerrr 11y ago
      If you can get it to exec some arbitrary bash command (or otherwise access the environ of a process) you can also have it cat any file on the server, and even the memory of the running processes that belong to the same user as the exploited process, and also execute network requests. So if you get that far, pretty much nothing will protect you.
      - smtddr 11y ago
        Sure, but there are some shops that do their security from a point-of-view of "Attacker can run commands on your server as the user that started whatever-public-service/webapp/api", and go from there. I happen to think that's the best way to think about it. Now, if an attacker manages to get root access then it's game over[1]. That just shouldn't happen. But nobody should be running their webserver as root. So, whatever that user is should be low-powered with only enough privileges to start the webserver & bind port 8080 (and use iptables or whatever to reroute connections to port 80 --> 8080) and the whole setup should be designed that this account won't be able to escalate things further if someone got a bash shell to it. ______ 1. You should at least have some way of detecting that it happened and consider all data & files compromised and just wipe the whole machine & start over. Or take that machine offline for investigation into what happened and put a fresh new one in its place.
        11y ago
- Dylan16807 11y ago
  When I test that, the command line does not include the variable-setting. Is this a problem that depends on version or are you mistaken? It would be kind of weird to include that considering how argv works.

ENV variables are inherited by child processes by default, so please use care when using this approach.

Here's my caution to this. If low level processes can do "ps aux", and they see something like: DB_USER=scott DB_PASSWORD=b3withm3pl3aze /usr/bin/python webapp.py That could be troublesome if an attacker figured out a way to run remote commands on your server even as an unprivileged user.

yrro 11y ago
Reading the environment of another process is a privileged operation.
- vidarh 11y ago
  The example above is someone who have stupidly started a process with the environment variables exposed on the command line
  - yrro 11y ago
    Ok, but that's not a problem caused by the exposure of the environment, it's caused by the exposure of the command line.
    - vidarh 11y ago
      I agree - I was just explaining what the issue the above commenter raised. It just means you should use a saner way of initializing your environment with sensitive values.
- smtddr 11y ago
  If an attacker can get the process that's running the webapp.py to exec some abitrary bash command, that process has the ability to read its own /proc/$PID/environ . In general, you can read /proc/$PID/environ on processes that you own. At least I can do that on my Debian system: pikachu@POKEMONGYM ~ $ sleep 99 & [1] 21340 pikachu@POKEMONGYM ~ $ cat /proc/21340/environ XDG_SESSION_ID=5COMP_WORDBREAKS= "'><;|&(:TERM=screenSHELL=/bin/bashXDG_SESSION_COOKIE=8571b679eed8952dd96ad28a54...<etc> (I actually gave the wrong example in my previous comment. While it is true that giving the ENV on cmdline will show up in ps eaux, the more appropriate example is what I just explained in this comment.)
  - tokenizerrr 11y ago
    If you can get it to exec some arbitrary bash command (or otherwise access the environ of a process) you can also have it cat any file on the server, and even the memory of the running processes that belong to the same user as the exploited process, and also execute network requests. So if you get that far, pretty much nothing will protect you.
    - smtddr 11y ago
      Sure, but there are some shops that do their security from a point-of-view of "Attacker can run commands on your server as the user that started whatever-public-service/webapp/api", and go from there. I happen to think that's the best way to think about it. Now, if an attacker manages to get root access then it's game over[1]. That just shouldn't happen. But nobody should be running their webserver as root. So, whatever that user is should be low-powered with only enough privileges to start the webserver & bind port 8080 (and use iptables or whatever to reroute connections to port 80 --> 8080) and the whole setup should be designed that this account won't be able to escalate things further if someone got a bash shell to it. ______ 1. You should at least have some way of detecting that it happened and consider all data & files compromised and just wipe the whole machine & start over. Or take that machine offline for investigation into what happened and put a fresh new one in its place.
      - 11y ago
Dylan16807 11y ago
When I test that, the command line does not include the variable-setting. Is this a problem that depends on version or are you mistaken? It would be kind of weird to include that considering how argv works.