5 ms·

> filesystem permissions are reasonably flexible Env makes things really flexible.For instance,you can call a program with env variables directly thus overri

by aikah 12y ago

> filesystem permissions are reasonably flexible Env makes things really flexible.For instance,you can call a program with env variables directly thus overriding the default ones,which simplify configuring applications. You dont have to have a test set-up,a production-setup or a staging set-up,just start a server or an app with different env variables in the command line. You don't want your config or keys to depend on an OS,or a language. Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them. I believe env variables are better than other solutions.

mschulze 12y ago
Spring Boot allows all of this at once [1]. You can specify a configuration file in your sources but if you set specific keys in the environment that configuration has a higher priority. I think this is a very good solution. Particularly this allows you to package a general configuration file, a user can provide an external configuration file and can for a specific instance even overwrite that with env (or command line arguments). [1] http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config http://docs.spring.io/spring-boot/docs/current/reference/htm...
mreinsch 12y ago
I agree that ENV variables are useful for general configuration, that's exactly what they were invented for... ENV variables are not restricted by user though, your process can spawn another process under a different user and give it the same environment. It's the nature of the environment that it is usually inherited from the parent which causes the issues when we're talking about secrets.
- geocar 12y ago
  Delete sensitive environment variables after you read them, or don't run programs you don't trust with an unsanitary environment/argument list (e.g. execve not system)
  - mreinsch 12y ago
    Thanks for that idea of deleting sensitive environment variables. I like that for hosters such as heroku which use ENV variables for config (including secrets) by default.
hueving 12y ago
>just start a server or an app with different env variables in the command line. Just reference a different config file on the command line. >You don't want your config or keys to depend on an OS,or a language. A path to a config file isn't an OS or language. The ini format is pretty widely supported. >Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them. This is exactly what filesystem permissions do for files already.
- geocar 12y ago
  BEGIN { $API = new Backend($ENV{credentials}); delete $ENV{credentials}; }; Filesystem permissions do not make it possible for a program to internally partition access to those credentials unless you (a) start it as root, or (b) delete the credentials file after reading it.
  - icebraining 12y ago
    A user process can start subprocesses under different users, without access permissions to the files owned by parent. The most obvious way to do so is to use sudo.
    - geocar 12y ago
      Using a setuid helper (even if it's called sudo) is still starting a program as root.
      - icebraining 12y ago
        Not necessarily; sudo on Fedora has CAP_SETUID instead of the setuid bit, so it doesn't actually run as root. http://fedoraproject.org/wiki/Features/RemoveSETUID http://fedoraproject.org/wiki/Features/RemoveSETUID
        ptx 12y ago
        But CAP_SETUID, unless I'm confusing it with something else, can be used to set the UID to 0 and thereby gain all the same privileges as if the program had been started as root, can't it? Presumably it has some advantage that I'm not getting – does it have to be combined with e.g. SELinux to be useful?
SwellJoe 12y ago
Maybe I'm old, but I remember way too many ENV exposure bugs over the years to be particularly confident dumping sensitive information into the ENV. Admittedly, all software should be sanitizing the ENV for untrusted users, but there's just such a long history of people making mistakes. I'm one of those people, in fact. Sure, frameworks and more modern execution models make it easier to avoid those mistakes today, but I've never accidentally checked in a config file with passwords (except a couple times in my t/ test directory, and that only for test server instances). I've made real data exposing security mistakes with ENV.

by aikah 12y ago

mschulze 12y ago

Spring Boot allows all of this at once [1]. You can specify a configuration file in your sources but if you set specific keys in the environment that configuration has a higher priority. I think this is a very good solution. Particularly this allows you to package a general configuration file, a user can provide an external configuration file and can for a specific instance even overwrite that with env (or command line arguments). [1] http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config http://docs.spring.io/spring-boot/docs/current/reference/htm...

mreinsch 12y ago

I agree that ENV variables are useful for general configuration, that's exactly what they were invented for... ENV variables are not restricted by user though, your process can spawn another process under a different user and give it the same environment. It's the nature of the environment that it is usually inherited from the parent which causes the issues when we're talking about secrets.

geocar 12y ago
Delete sensitive environment variables after you read them, or don't run programs you don't trust with an unsanitary environment/argument list (e.g. execve not system)
- mreinsch 12y ago
  Thanks for that idea of deleting sensitive environment variables. I like that for hosters such as heroku which use ENV variables for config (including secrets) by default.

hueving 12y ago

>just start a server or an app with different env variables in the command line. Just reference a different config file on the command line. >You don't want your config or keys to depend on an OS,or a language. A path to a config file isn't an OS or language. The ini format is pretty widely supported. >Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them. This is exactly what filesystem permissions do for files already.

geocar 12y ago
BEGIN { $API = new Backend($ENV{credentials}); delete $ENV{credentials}; }; Filesystem permissions do not make it possible for a program to internally partition access to those credentials unless you (a) start it as root, or (b) delete the credentials file after reading it.
- icebraining 12y ago
  A user process can start subprocesses under different users, without access permissions to the files owned by parent. The most obvious way to do so is to use sudo.
  - geocar 12y ago
    Using a setuid helper (even if it's called sudo) is still starting a program as root.
    - icebraining 12y ago
      Not necessarily; sudo on Fedora has CAP_SETUID instead of the setuid bit, so it doesn't actually run as root. http://fedoraproject.org/wiki/Features/RemoveSETUID http://fedoraproject.org/wiki/Features/RemoveSETUID
      - ptx 12y ago
        But CAP_SETUID, unless I'm confusing it with something else, can be used to set the UID to 0 and thereby gain all the same privileges as if the program had been started as root, can't it? Presumably it has some advantage that I'm not getting – does it have to be combined with e.g. SELinux to be useful?

SwellJoe 12y ago

Maybe I'm old, but I remember way too many ENV exposure bugs over the years to be particularly confident dumping sensitive information into the ENV. Admittedly, all software should be sanitizing the ENV for untrusted users, but there's just such a long history of people making mistakes. I'm one of those people, in fact. Sure, frameworks and more modern execution models make it easier to avoid those mistakes today, but I've never accidentally checked in a config file with passwords (except a couple times in my t/ test directory, and that only for test server instances). I've made real data exposing security mistakes with ENV.